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Foreword 



This Technical Specification (TS) has been produced by ETSI Project Digital Enhanced Cordless Telecommunications 
(DECT). 

The present document is based on EN 300 175, parts 1 [1] to 8 [8] , EN 300 444 [15] and EN 301 649 [16]. General 
attachment requirements and speech attachment requirements are based on EN 301 406 [11] (replacing TBR 006 (see 
bibliography)) and EN 300 176-2 [10] (previously covered by TBR 010 (see bibliography)). 

The present document has been developed in accordance to the rules of documenting a profile specification as described 
in ISO/IEC 9646-6 [12]. 

The information in the present document is believed to be correct at the time of publication. However, DECT 
standardization is a rapidly changing area, and it is possible that some of the information contained in the present 
document may become outdated or incomplete within relatively short time-scales 

The present document is part 2 of a multi-part deliverable covering the New Generation DECT as identified below: 

Part 1: "Wideband speech"; 

Part 2: "Support of transparent IP packet data"; 

Part 3: "Support of phase 2 services". 
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1 Scope 

The present document specifies a set of functionalities of the New Generation DECT. 

The functionaHties defined in this profile are based on DECT base standard, EN 300 175, parts 1 [1] to 8 [8] , DECT 
Generic Access Profile (GAP), EN 300 444 [15], and DECT Packet Radio Service (DPRS), EN 301 649 [16]. 

The New Generation DECT provides the following basic new functionaUties: 

• Wideband voice service. 

• Packet-mode data service supporting Internet Protocol with efficient spectrum usage and high data rates. 

The present document describes the second part: packet-mode data service supporting Internet Protocol with efficient 
spectrum usage and high data rate. For description of the Wideband voice service see TS 102 527-1 [17]. 

All New Generation DECT devices will offer at least one or both of these services. If the device offers the wideband 
voice service, it will support also the DECT standard 32 kbit/s voice service according to EN 300 444 [15] (GAP). 

All DECT devices claiming to be compliant with this Application Profile will offer at least the basic services defined as 
mandatory. In addition to that, optional features can be implemented to offer additional DECT services. 

The aim of the present document is to guarantee a sufficient level of interoperability and to provide an easy route for 
development of DECT data applications, with the features of the present document being a common fall-back option 
available in all compliant to this profile equipment. 

DECT does not standardize Internet Application protocols or other high layer data protocols, which are in the scope of 
other standarization organizations. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in EN 301 649 [16] shall apply. 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

BA The part from the A-field that provides indication for the content of the B-field of one MAC layer 

packet 

C For conditional to support (process mandatory) 

I For irrelevant or out-of-scope (provision optional, process optional), not subject for testing 

Ip Higher layer Information channel (protected) 

Lc DLC layer C-plane protocol entity 

M For mandatory to support (provision mandatory, process mandatory) 

Mj MAC control, one M-channel message 

N Identities channel 

N/A For not-applicable (in the given context the specification makes it impossible to use this 

capability) 

Nj Identities information, one N-channel message 

O For optional to support (provision optional, process mandatory) 

O.x Option comprising number of items 

Pj One P-channel message 

Q System information channel 

Qj System information and multiframe marker 

Sip Higher layer connectionless channel (protected) 

WtA Waiting time A 

WtB Waiting time B 

X Excluded, not allowed 

The symbols defined in this clause are applied for procedures, features, and services in the present document if not 
explicitly otherwise stated. The interpretation of status columns in all tables is as follows: 

• Provision mandatory, process mandatory means that the indicated feature service or procedure shall be 
implemented as described in the present document, and may be subject to testing. 

• Provision optional, process mandatory means that the indicated feature, service or procedure may be 
implemented, and if implemented, the feature, service or procedure shall be implemented as described in the 
present document, and may be subject to testing. 

NOTE: The used notation is based on the notation proposed in ISO/IEC 9646-7 [13]. 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AC Authentication Code 

ACK ACKnowledgement 

AI/F Air InterFace 

ARC Access Rights Class 

ARD Access Rights Details 

ARl Access Rights Identity 

ARQ Automatic Retransmission reQuest 

ASAP Application Specific Access Profile 
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BCD 
C 



Binary Coded Decimal 
higher layer control Channel 



NOTE: See C^ and Cp. 



C/L 
CC 



ConnectionLess 
Call Control 



NOTE: A NWK layer functional grouping. 

CI Common Interface 

Cp higher layer signalling Channel (Fast) 

CLIP Calling Line Identification Presentation 

CLMS ConnectionLess Message Service 

C-plane Control plane 

CRC Cyclic Redundancy Check 

Cg higher layer signalling Channel (Slow) 

CSMA/CD Carrier Sense Multiple Access with Collision Detection 

DCDL-net Distributed Communication DECT Local network 

DCE Data Circuit terminating Equipment 

DCK Derived Cipher Key 

DECT Digital Enhanced Cordless Telecommunications 

DHCP Dynamic Host Configuration Protocol 

DEC Data Link Control 

DPRS Data Packet Radio Service 

DSC Data System Categories 

DTE Data Terminal Equipment 

DTMF Dual Tone Multi-Frequency 

ECN Exchanged Connection Number 

EFREL Enhanced Frame RELay service 

E+U Mode of the B-field E/U multiplexer carrying U-plane data and signalling 

FP Fixed Part 

FREE Frame RELay 

FT Fixed radio Termination 

FTP File Transfer Protocol 

FUlO Frame structure for U-plane service 10 

NOTE: See EN 300 175-4[4]. 



GAP 

GSM 

GPRS 

HDLC 

HTTP 

HyP 

I 



IETF 
IMS 

In 
IP 

IpF 

IpQ 

ISDN 

IWF 

IWU 

L 

LA 

LAN 

LBN 



Generic Access Profile 
Global System Mobile 
General Packet Radio Service 
High level Data Link Control 
HyperText Transfer Protocol 
Hybrid Part 
higher layer Information channel 



NOTE: See Lt and I 



N' 



Internet Engineering Task Force 

IP Multimedia Subsystem 

higher layer Information channel (unprotected) 

Internet Protocol 

higher layer U-plane channel in Eh-U mode slots 

higher layer Information channel (protected) single B-field 

Integrated Services Digital Network 

InterWorking Functions 

InterWorking Unit 

Length 

Location Area 

Local Area Network 

Logical Bearer Number 
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LCE 


Link Control Entity 


LLC 


Logical Link Control 


LLME 


Lower Layer Management Entity 


LLN 


Logical Link Number 


LUlO 


LAP-U service 10 


NOTE: See 


EN 300 175-4[4]. 


M 


MAC control channel 


MAC 


Medium Access Control 


MBC 


Multi Bearer Control 


ME 


Management Entity 


MIME 


Multipurpose Internet Mail Extensions 


MM 


Mobility Management 


MMSC 


Mobility Management Service Class 


MSB 


Most Significant Bit 


MTU 


Maximum Transmission Unit 


MUX 


time Multiplexors 


NAT 


Network Address Translator 


NG-DECT 


New Generation DECT 


NWK 


NetWorK 


ODAP 


Open Data Access Profile 


P 


Paging channel 


PABX 


Private Automatic Branch eXchange 


PAD 


Packet Assembler-Disassembler 


PAT 


Port Address Translator 


PARK 


Primary Access Rights Key 


PDP 


Packet Data Protocol 


PDU 


Protocol Data Unit 


PHL 


PHysical Layer 


PHY 


PHYsical 


PMID 


Portable part MAC IDentity 


PP 


Portable Part 


PPP 


Point-to-Point Protocol 


PSTN 


Public Switched Telephone Network 


PT 


Portable radio Termination 


PVC 


Permanent Virtual Circuit 


Qh 


Q field header 


RFC 


Request For Comment 


RFP 


Radio Fixed Part 


RFPI 


Radio Fixed Part Identity 


RTP 


Real-time Transport Protocol 


RTSP 


Real-Time Streaming Protocol 


SAP 


Service Access Point 


SARI 


Secondary Access Rights Identity 


SDU 


Service Data Unit 


SIP 


Session Initiation Protocol 


SIpp 


Higher layer connectionless channel in Eh-U mode slots 


SOHO 


Small Office and Home Office 


SMTP 


Simple Message Transport Protocol 


TARI 


Tertiary Access Rights Identity 


TCP 


Transmission Control Protocol 


TDD 


Time Division Duplex 


TDMA 


Time Division Multiple Access 


TPUI 


Temporary Portable User Identity 


UDP 


User Datagram Protocol 


UMTS 


Universal Mobile Telecomunication System 


U-pIane 


User-plane 


VC 


Virtual Calls 


WLAN 


Wireless Local Area Network 
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4 Description of Services 

4.1 The data service in New Generation DECT 

4.1 .1 Service objectives 

At the moment of drafting of the present document the Internet Protocol has been consolidated as the universal data 
standard able to transport any application or service, and able of being transported by any transmission media. 

The DECT community has recognized this reality a long time ago, and DECT specification includes mechanisms for 
efficient transport of Internet protocol and the application protocols on top of that. 

The DECT Packet Radio Service (DPRS) [16] is the DECT specification for the transport of packet-mode data. It 
includes powerful mechanisms providing context control, mobility management and security, and takes advantage of 
powerful features of the DECT common interface to offer a high performance data transport mechanism. 

The data service in New Generation DECT is based on the efficient transport of Internet protocol (IP) [19] and takes 
advantage of the work done by IETF and the IT industry to cover a wide range of services and applications (figure 1). 
Furthermore, by using this approach, DECT will be able to provide further applications and services to be developed in 
the future. 

The present document selects a specific set of features from DPRS and defines an interoperability profile. The aim of 
the specification is to guarantee interoperability at IP level, and to provide an easy route for development of DECT data 
applications. 

4.1 .2 Cinaracteristics of tine DECT packet data service 

The DECT packet data service provides an efficient transparent transport of IP and upper layers with the following 
characteristics: 

Packet mode: the service provided by DECT uses only the air interface resources when there are data to be transported, 
allowing re-use of the spectrum by statistical multiplexing between multiple users and systems 

Connection Oriented: the service provided by DECT provides controlled and isolated logical paths between 
ends -Virtual Circuits - that can be permanent or switched. The fact that DECT provides a connection oriented service 
does not introduce any kind of restriction when transporting connectionless protocols (like IP), and provides important 
advantages regarding the security and mobility management. It is also possible to have in the same DECT system 
several data networks completely isolated from one another. 

Complete mobility management: DECT provides complete mobility management (handover, roaming) like a cellular 

system. 

Security: DECT provides serious authentication and ciphering exactly as a cellular system (i.e. GSM). Ciphering is 
performed at MAC layer using a dedicated hardware and does not consume application processing power 

Asymmetric connections: DPRS makes use of the TDD characteristic of DECT to revert the transmission direction of 
the bearers, doubling the transmission speed of the system. This process is performed automatically and continuously 
by the system in order to optimize transmission speed. There is no a pre-set direction of transmission. The system could 
move from maximum speed downlink to maximum speed uplink according to the data to be transmitted. 

High Speed: DECT offers transmission speeds of up to 5,068 Mbit/s with 64 QAM modulation. In the present 
document, the simpler GFSK modulation schema is used allowing a maximum transmission speed of 
845 kbit/s + 57,6 kbit/s asymmetric or 460 kbit/s + 460 kbit/s symmetric. 

The capabilities offered by DECT are similar to a cellular communication system like GPRS or UMTS. 
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Table 1 : Summary of service capabilities 



Service 


FT 


PP 


Point-to-point protected data transfer PP-FP with ARQ 


YES 


YES 


Point-to-point protected data transfer FP-PP with ARQ 


YES 


YES 


Point-to-multi-point data transfer FP-PP 


OPTIONAL 


OPTIONAL 


Authentication 


YES 


YES 


Encryption 


YES 


YES 


Permanent Virtual Circuit (PVC) operation 


YES 


YES 


Virtual Call (VC) operation 


YES 


YES 


Intra-cell bearer handover (see note) 


YES 


YES 


Inter-cell bearer handover (see note) 


YES 


YES 


Inter-cell connection handover (for multicell systems) 


OPTIONAL 


OPTIONAL 


Inter-cell external handover 


OPTIONAL 


OPTIONAL 


NOTE: Bearer handover capability may be provided by the bearer replacement 
procedure. 



4.2 



Protocol architecture 



Although the primary objective is to guarantee IP transparency, and this service is provided by DPRS [16], the present 
specification (New Generation DECT, part 2) privileges the Interworking function at IEEE 802.3 level (annex B.4 of 
DPRS is Mandatory for PP and FP). However, the Interworking function at IP level is also allowed as an option 
(annex B.6 of DPRS is optional for PP and FP). 

Annex B.4 of DPRS means that part of the IEEE 802.3 header is transported by the air interface. This is done to 
simplify implementations in many systems that are likely to have external Ethernet interfaces. Only part of the 
IEEE 802.3 header is transported by air interface. 

In the case of scenarios or applications with no external Ethernet stacks, either the "Direct IP" solution is used 
(annex B.6 of DPRS), or an IEEE 802.3 header with conventional addresses should be added for transporting the data 
over air interface using DPRS annex B.4 configuration. DECT does not use the IEEE 802.3 header for routing or 
addressing. 

4.2.1 IPv6 

IP version 6 (IPv6) [22] can also be used with no difference compared to IPv4 [19]. 

4.2.2 Other LAN protocols: DHCP, ARP, RARP 

Due to the Mandatory support of Interworking function at IEEE 802.3 level, other protocols commonly transported by 
Ethernet Networks can always be transparently transported by the DECT system if needed. It includes DHCP [23], 
ARP [24], and RARP [25]. 

4.2.3 Data protocol reference configuration 

The described view of IP as a universal transport is summarized in figure 1 . 

The present document allows two reference configurations for transporting IP data over DECT: 

• IEEE 802.3 (or Ethernet) frames over DECT layers (use of DPRS annex B4). 

• IP datagrams directly transported by DECT layers (use of DPRS annex B6). 
The reference model for both configurations is described in the following clauses. 



£75/ 



14 



ETSI TS 102 527-2 VI. 1.1 (2007-06) 




4.2.3.1 



Figure 1 : Data services simplified Reference Configuration 



IEEE 802.3/Ethernet over DECT (DPRS annex B.4) reference configuration 



The reference model of the data protocol stacks at air interface and Interworking functions is depicted in figures 2 
and 3. 
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Figure 2: IEEE 802.3/Ethernet over DECT (use of DPRS annex B4): U-plane stack 
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DECT MAC 


DECT PHL 
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4.2.3.2 



PT Boxes in grey are a direct consequence of the current standard. ft 

Boxes in white are implementation choices dependant. 

Figure 3: IEEE 802.3/Ethemet over DECT (use of DPRS annex B4): C-plane stack 

Internet Protocol (IP) over DECT (DPRS annex B.6) reference configuration 



The reference model of the data protocol stacks at air interface and Interworking functions is depicted in figures 4 
and 5. 
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Figure 4: Internet Protocol (IP) over DECT (use of DPRS annex B6): U-plane stack 
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Figure 5: Internet Protocol (IP) over DECT (use of DPRS annex B6): C-plane stack 
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4.2.3.3 



Other implementation options 



A DECT system could include additional routing, protocol handling or interworking functions at higher levels. A 
typical case is the Internet Protocol routing with or without NAT. This is irrelevant from the point of view of DECT and 
does not require any provision in the present document. Furthermore, PP should be interoperable irrespective of the 
implementation option at the FP. As example for implementers, the next figure shows the likely case of a PP with 
external LAN interface, IEEE 802.3/Ethernet transported over DECT (DPRS annex B.4) plus IP routing at FP. 





^^^^ IWF: IP routing ^^ 
IP ^^^ ^^ IP 


DPRS Annex B.4 header 
IEEE 802.3 




DECTNWK 


DECT DLC 

U-plane 
LUIO/FUIO 


IEEE 802.3 or 
Ethernet DLC 
and MAC layers 


DECTDLC 

C-plane 


DECT MAC 


IEEE 802.3 or 
Ethernet PH layer 


DECT PHL 



Figure 6: Option of IEEE 802.3/Etliernet transport (DPRS annex B.4) withi IP routing at FP 



4.3 Performance Objectives 



The performance characteristics figures are shown in table 2. The table defines the applicable performance figures for a 
system designed to achieve the full capability provided by the standard. Due to the nature of radio transmission and 
packet data in general, figures could be lower in case of bad radio links, or spectrum usage competition from other 
system. 

Table 2: Performance objectives 



Performance parameter 


Value 


Notes 


Maximum transportable packet size without IP segmentation 


> 1 528 octets 


See note 1 


IVIaximum one-way delay 


Down to 50 ms 
configurable 


See note 2 


Maximum sustainable unidirectional throughput (per slot) 


76,8 kbit/s net 


See notes 3 and 4 


Maximum sustainable unidirectional throughput (per transceiver) 


844,8 kbit/s net 


See notes 3 and 4 


Maximum sustainable full bi-directional throughput (per transceiver) 


460,8 kbit/s net 


See notes 3 and 4 


Maximum system sustainable unidirectional throughput (per a system 
composed of 1 transceivers) 


8,448 Mbit/s 

(10 parallel unidirectional 

connections) 


See notes 3 and 4 


Total bandwidth available to be shared between all transmitters in an 
area (assuming 10 frequencies) 


9,216 Mbit/s 
(10 frequencies) 


See notes 3, 4 and 5 


Establishment of PI to FT physical connection (average) 


< 50 ms 


See note 2 


Establishment of FT to PT physical connection (average) 


< 50 ms 


See note 2 
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Performance parameter 


Value 


Notes 


Undetected bit error ratio 


< 10-10 




Uncorrected bit error ratio (for air interface BER 10"^ and delay = 100 
ms) 


<io-^ 




NOTE 1 : This is the MTU (IVIaximum Transmission Unit). This figure is compatible with IEEE 802.3 and IP, and does not 

introduce any restriction. 
NOTE 2: Figures could be impossible to achieve in case of competition acceding the air interface between several 

terminals or systems. 
NOTE 3: Net user data rate available for high layer protocols without considering the DECT overheads. 
NOTE 4: Assuming double slot and MAC service IpQ 

NOTE 5: Assuming the 1 frequencies available in the original DECT frequency spectrum 1 880 MHz to 1 900 MHz. In 
several countries, frequencies are available at 1 900 MHz to1 920 MHz, 1 910 MHz to 1 930 MHz, and ISM 
band. 



4.4 System Categories 



New Generation DECT data systems are classified in categories depending on the data performance objectives of the 
system. Each category has specific requirements, additional to the general features and services applicable to all 
NG-DECT data systems. Table 3 defines the mandatory requirements for each category. 

The declaration of data category is optional. It is possible to have NG-DECT data systems not belonging to any data 
category. Such systems are called "non categorized" systems. However, the alignment to one (or several) categories is 
advisable in order to improve interoperability. 

The following categories are defined: 

• Category 1: Low-end systems providing a symmetric data rate of 50 kbit/s over a single bearer, using long 
slot. 

• Category 2: Mid-end multibearer systems providing a data rate up to 500 kbit/s supporting symmetric and 
asymmetric connections. 

• Category 3: High-end systems providing a data rate up to 844 kbit/s supporting symmetric and asymmetric 
connections. 

Category 2 uses long slots (j=640), which is convenient for slow hopping radios. Category 3 uses double slots and 
MAC service IpQ and is intended to achieve higher data rates. 

Clause 5.2, tables 3 and 4, defines the mandatory features and services for each NG-DECT data category. Such 
mandatory requirements should be understood as additional to the base requirements that are applicable to all 
NG-DECT data systems. 

NG-DECT data categories are back compatible in the following way: 

• NG-DECT Data Category 2 systems shall support also Category 1 . 

• NG-DECT Data Category 3 systems shall support also Categories 1 and 2. 

When FP and PP do not have the same Category, the features of the highest category supported by both sides shall be 
used. 



£75/ 



18 ETSI TS 102 527-2 VI. 1.1 (2007-06) 

4.5 General application environments 

The following clause introduces some potential application scenarios as guidance. This clause is not exhaustive and is 
provided as application example. There will be more applications and scenarios not covered by this clause. 

4.5.1 Residential (home networking) environment 

In the residential scenario, the user typically operates a single DECT FP with external connection to Internet or to a 
dedicated data IP network by means of ADSL, xDSL, Cable, ISDN or PSTN. Several DECT PPs are connected to the 
DECT FP, creating a wireless home network with voice and data capability. This capability can be used for many 
applications: 

1) Wireless LAN service. 

The DECT network provides a Wireless LAN service that can be used for interconnection of computer 
equipment between them, and with the Internet. The provided Wireless LAN service has a data rate similar to 
initial versions of IEEE 802.11 (=1 Mbit/s) and can be enough for many scenarios. 

In addition to these computer-oriented applications, there are many other data applications where DECT technology is 
especially suitable. 

2) Auxiliary functions of voice DECT terminals (address book, SMS, etc.). 

An advanced DECT voice terminal could incorporate DPRS capabilities in order to provide auxiliary services 
like a shared address book centralized in the FP. A similar function could be the browsing of short messages or 
MMS stored in the Fixed Part. For these scenarios DECT data is by far the most convenient implementation. 

3) Multimedia capability (I.e. video conference) in DECT terminals. 

Multimedia capabilities can be easily provided using SIP or IMS on top of the transparent IP transport 
provided by DECT. Service can be based on IMS (3GPP) protocols, or a more simplified approach. 

4) Interconnection with set-top boxes and consumer electronics equipment. 

The DECT device could be used for implementation of interactive data communication with audio/video, 
video-games and other consumer electronics equipment. 
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Figure 7: Home Wireless LAN based on DECT - FT implemented 
as a Router (including Gateway); Voice and data capability in the same radio network 
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Figure 8: Wireless Ethernet connection to a Set-top box (e.g. Cable or xDSL modem) 

providing data and voice service 
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4.5.2 Business scenario 



Contrary to the Residential/Private environment, the enterprize environment is characterized by a controlled 
distribution, installation of radio base stations and by the use of specially dedicated terminals. The DECT technology is 
widely used in this scenario for voice service. It allows the creation of a micro-cellular private network with all the 
features commonly associated to the public mobile service, as high security or handover capabilities. The radio 
properties of DECT make possible a systematic planning of the radio network, which is the basis of a predictable high 
quality service. All these advantages can be extended to data applications, adding the support of DPRS to the DECT 
system. 

The DECT data in a corporate environment allows the provision of a reasonable rate Wireless LAN service (1 Mbit/s in 
DECT 2-level modulation) using the same radio infrastructure as the voice services. It means that only one set of base 
stations will be needed, and that existing radio planning can be reused. The DECT network is designed for systematic 
coverage (cellular) of large areas, and can be the right choice for many applications. It should be noted also that DECT 
provides a reduced power consumption and RF radiated power compared with other technologies. 

This DECT capability can be used for many applications: 

1) Cellular Wireless LAN service. 

DECT provides a wireless LAN service with reasonable data rate and handover capabilities. This service can 
be designed for predictable, systematic coverage of large areas. It can be used for computer interconnection to 
corporate LANs. Compared to other technologies, the service is specially convenient for nomadic devices. 

2) Wireless LAN service in restricted areas. 

The radio properties of DECT (dedicated band, low power) make it convenient for operation in scenarios 
where other technologies operating in the ISM band can not be used. It includes medical, aeronautical or 
industrial applications. 

3) 3) Specific industrial, control or security applications. 

The DECT advantage when the important point is a systematic, predictable coverage, makes it suitable for 
industrial applications, as interconnection between control systems and industrial equipment. The same is 
applicable to security applications (i.e. alarms). Such applications include: 

Hospital, medical equipment and biological sensors. 

Hotel and restaurant environments: dedicated equipment for personnel. 

Point-of-sale applications (order entry, credit card processing, checking available stock). 

Warehouses: inventory applications (bar-code reading, etc). By updating stock information in real-time, 
significant savings can be achieved by reducing the inventory. 
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Figure 10: Business scenario: DECT Wireless LAN for remote 
retrieval of information from a system of sensors 
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4.5.3 Small Office and Home Office (SOHO) 

The SOHO environment may be considered in most cases as either a minimized rephca of the enterprize environment, 
or, as a magnified rephca of the residential private environment, therefore all of the examples given that are relevant for 
the enterprize or for the residential private environments may be applied. 

4.6 Examples of implementation of most usual scenarios 
4.6.1 Fixed Part (FP) acting as a router with WLAN/DECT access point 




Phone 




LAN 



Figure 1 1 : Network example with FP acting as router 

In this implementation, the DECT FP implements an IP routing function and includes IEEE 802.3 interfaces to LAN(s). 
This use case can be applicable to home, enterprize or soho scenarios. 

The configuration parameters for each client participating in the IP network are provided by the DHCP server of the FP, 
which also has router functionality in this example. Each client has its own Ethernet MAC address. The FP has one 
Ethernet MAC address for the LAN and one for the WAN side. 

The routing function at FP can be complemented with NAT and PAT, if required by the IP addressing plan. 
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4.6.2 Fixed Part (FP) acting as a switcin witin WLAN/DECT access point 




Phone 



Figure 12: Network example with FP acting as switcli 

As alternative, it is possible to build the implementation with only LAN switching function at the DECT FP. In this 
case, the DECT FT acts as a LAN switch with IEEE 802.3 interfaces. In this implementation, the same LAN transported 
by DECT air interface is accessible at the FT Ethernet port. This use case is applicable to home, enterprize or SOHO 
scenarios. 

The configuration parameters for each client participating in the LAN are provided by a DHCP server, usually 
collocated with a LAN router (external to the DECT FT). Each client has its own Ethernet MAC address. 



Relevant requirements 



The requirements of EN 301 649 [16] relevant for Class 2 equipment shall apply with the modifications stated in 
clauses 5 and 6 of the present document. 

The encapsulation of external data protocol shall be done as stated in EN 301 649 [16], annex B.4. 

In any case, the requirements of EN 300 176-1 [9] and any of the harmonized standard EN 301 406 [11] shall apply as 
well. 



5.1 



Service and feature definitions 



5.1.1 PHL service definitions 

For the purpose of the present document, the definitions of EN 301 649 [16], clause 4.3.1 shall apply. 

5.1 .2 MAC service definitions 

For the purposes of the present document, the definitions of EN 301 649 [16], clause 4.3.2 shall apply. 
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5.1 .3 DLC service definitions 

For the purposes of the present document, the definitions of EN 301 649 [16], clause 4.3.3 shall apply. 

5.1 .4 NWK feature definitions 

For the purposes of the present document, the definitions of EN 301 649 [16], clause 4.3.4 shall apply. 

5.1 .5 Application service definitions 

For the purposes of the present document, the definitions of EN 301 649 [16], clause 4.3.5 shall apply. 

5.1 .6 Management Entity (ME) definitions 

For the purposes of the present document, the definitions of EN 301 649 [16], clause 4.3.7 shall apply. 

5.1 .7 Call Control (CC) and mobility management service definitions 

For the purposes of the present document, the definitions of EN 301 649 [16], clause 4.3.8 shall apply. 

5.1 .8 U-plane service and interworking definitions 

For the purposes of the present document, the definitions of EN 301 649 [16], clause 4.3.9 shall apply. 

5.1 .9 NG-DECT Data System Categories (DSC) 

For the purposes of the present document, the following definitions shall apply: 

Category 1 [NG-DECT-Cat.l]: low-end systems providing a symmetric data rate of 50 kbit/s over a single bearer, 
using long slot 

Category 2 [NG-DECT-Cat.2]: mid-end multibearer systems providing a data rate up to 500 kbit/s supporting 
symmetric and asymmetric connections 

Category 3 [NG-DECT-Cat.3]: high-end systems providing a data rate up to 844 kbit/s supporting symmetric and 
asymmetric connections 

5.2 Requirennents applicable to categorized systems 

The following requirements apply to NG-DECT data systems declaring compliance to one or more NG-DECT/DPRS 
data category (see also clause 4.4). 

5.2.1 Mapping between NG-DECT data categories and features/services 

Equipment belonging to each NG-DECT data category type shall support the features and services defined in the 
following table and shall use these features/services when establish communication with other systems belonging to the 
same category. 
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For features/services not listed in table 3, the status defined in clause 6 shall apply: 

Table 3: Features/services supported for each NG-DECT data system category 



NG-DECT data Category to feature/service mapping 


Category 


NG-DECT data Feature/Service 


Reference 


Note 


Status 1 


PT 


FT 


[NG-DECT-Cat.1] 
Category 1 systems 




4.4,5.1.9 








GFSK modulation [DPRS-P.1]: 


4.3.1 [16] 




M 


M 


Physical Packet P64 [DPRS-P.1 4]: 


4.3.1 [161 




M 


M 


lp_error_detection IVIAC service type 
[DPRS.M.6] 


4.3.2 [16] 




M 


M 


lp_error_correction IVIAC service type 
[DPRS.M.7] 


4.3.2 [16] 










Gp channel [DPRS-M. 19] 


4.3.2 [16] 




C31 


C31 


Ipp channel [DPRS-M.23] 


4.3.2 [16] 




C31 


C31 


Long slot 640 [DPRS-M.25] 


4.3.2 [16] 




M 


M 


Multibearer connections [DPRS-M. 28] 


4.3.2 [16] 










Asymmetric connections [DPRS-M.29] 


4.3.2 [16] 










Class 2 Management [DPRS-ME.2] 


4.3.7 [16] 


2 


M 


M 


Service Class 2 [DPRS-G.2J 


4.3.8 [16] 


2 


M 


M 


[NG-DECT-Cat.2] 
Category 2 systems 


GFSK modulation [DPRS-P.1] 


4.3.1 [16] 




M 


M 


Physical Packet P64 [DPRS-.P.14] 


4.3.1 [16] 




M 


M 


lp_error_detection MAC service type 
[DPRS.M.6] 


4.3.2 [16] 




M 


M 


lp_error_correction MAC service type 
[DPRS.M.7] 


4.3.2 [16] 










Gp channel [DPRS-M.19] 


4.3.2 [16] 




M 


M 


Ipp channel [DPRS-M.23] 


4.3.2 [16] 




M 


M 


Long slot 640 [DPRS-M.25J 


4.3.2 [16] 




M 


M 


Multibearer connections [DPRS-M. 28] 


4.3.2 [16] 




M 


M 


Asymmetric connections [DPRS-M.29] 


4.3.2 [16] 




M 


M 


Class 2 Management [DPRS-ME.2] 


4.3.7 [161 


2 


M 


M 


Service Class 2 [DPRS-G.2J 


4.3.8 [16] 


2 


M 


M 


Category 1 operation [NG-DECT-Cat.l] 


4.4,5.1.9 


3 


M 


M 


[NG-DECT-Cat.3] 
Category 3 systems 


GFSK modulation [DPRS-P.1] 


4.3.1 [16] 




M 


M 


Physical Packet P80 [DPRS-.P.16] 


4.3.1 [16] 




M 


M 


lpQ_error_detection MAC service type 
[DPRS.M.20] 


4.3.2 [16] 




M 


M 


lpQ_error_correction MAC service type 
[DPRS.M.21] 


4.3.2 [16] 










Gp channel [DPRS-M.19] 


4.3.2 [16] 




M 


M 


Ipp channel [DPRS-M.23] 


4.3.2 [16] 




M 


M 


Double slot [DPRS-M.27] 


4.3.2 [16] 




M 


M 


Multibearer connections [DPRS-M. 28] 


4.3.2 [16] 




M 


M 


Asymmetric connections [DPRS-M.29] 


4.3.2 [16] 




M 


M 


Class 2 Management [DPRS-ME.2] 


4.3.7 [16] 


2 


M 


M 


Service Class 2 [DPRS-G.2J 


4.3.8 [161 


2 


M 


M 


Category 1 operation [NG-DECT-Cat.l] 


4.4,5.1.9 


4 


M 


M 


Category 2 operation [NG-DECT-Cat.2] 


4.4,5.1.9 


4 


M 


M 


C31 : IF DPRS-M.29 is supported THEN M ELSE 0. 


NOTE 1 : There can be non categorized NG-DECT data systems 

NOTE 2: All categories are based on Class 2 management and Service Class 2. 

NOTE 3: Category 2 systems shall also support all features of Category 1 systems and shall be able to interoperate 

with them. 
NOTE 4: Category 3 systems shall also support all features of Category 1 and Category 2 systems and shall be 

able to interoperate with them. 
NOTE 5: In the case where a FP and a PP do not have the same category capabilities, the initiating side should 

use the highest category supported by both sides. 
NOTE 6: The reference column refers to the relevant clause in the present or in the referenced document. 
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5.2.2 Supported data rates for equipment declaring compliance to a data 
category 

Equipment belonging to each NG-DECT data category type shall support, at least, the following number of active slots 
and data rates described as mandatory in table 4. They may optionally support the number of active slots and data rates 
described as optional in table 4. 

NOTE: The mandatory supported data rate has been chosen to allow two simultaneous wideband calls 
(see TS 102 527-1 [17]) in addition to the data transfer. 

Table 4: Supported data rates for each system Category 



Supported data rates for each system category 


Category 


Parameter 


Notes 


Value 1 


Data rates in kbit/s 

(see notes 1 and 2) 


Corresponding number 
of bearers 


downlink 
(FT > PT) 


uplink 
(PT > FT) 


downlink 
(FT > PT) 


uplink 
(PT > FT) 


NG-DECT-Cat.1 
Category 1 systems 


Mandatory supported data-rate for 
symmetric connections 


4 


51,2 


51,2 


1 


1 


NG-DECT-Cat.2 
Category 2 systems 


Mandatory supported data rate for 
symmetric connections 


4,5 


204,8 


204,8 


4 


4 


Optional maximum data rate for 
symmetric connections 


4,6 


307,2 


307,2 


6 


6 


Mandatory supported downlink 
data rate for asymmetric 
connections 


4,5, 
7,3 


358,4 


44,8 


7 


1 


Optional maximum downlink data 
rate for asymmetric connections 


4,6,8 


563,2 


44,8 


11 


1 


Optional maximum uplink data 
rate for asymmetric connections 


4,6,8 


44,8 


563,2 


1 


11 


NG-DECT-Cat.3 
Category 3 systems 


Mandatory supported data rate for 
symmetric connections 


9,5 


307,2 


307,2 


4 


4 


Optional maximum data rate for 
symmetric connections 


9,6 


460,8 


460,8 


6 


6 


Mandatory supported downlink 
data rate for asymmetric 
connections 


9,5, 
7,3 


537,6 


57,6 


7 


1 


Optional maximum downlink data 
rate for asymmetric connections 


9,6,8 


844,8 


57,6 


11 


1 


Optional maximum uplink data 
rate for asymmetric connections 


9,6,8 


57,6 


844,8 


1 


11 


NOTE 1 : Data rate indicates net data rate provided by IVIAC layer. 

NOTE 2: The value of the backward rate in asymmetric connections includes the reduction by using the Ipp 

channel due to the insertion of the "Quality control message" in all frames. 
NOTE 3: The asymmetric uplink configuration is not mandatory. 
NOTE 4: Slot type shall be Long slot (j=640) with MAC service Ip. 

NOTE 5: The system shall support all intermediate number of bearers between the minimum 1 +1 and this value. 
NOTE 6: The system may optionally support higher number of bearers than the mandatory configuration. If 

supported, the system shall support all intermediate values between 1+1 and the claimed maximum. 
NOTE 7: In asymmetric connections, the system shall support all intermediate values in the number of duplex 

bearers from 1 to the mandatory value for symmetric connections, plus all intermediate values in the 

number of double simplex bearers from 1 to the necessary to fulfil the mandatory asymmetric rate. 

However it does not need to support a higher number of bearers in total than the used in a 1+N full 

asymmetric case. 
NOTE 8: If the system claims a higher value of asymmetric bearers than the mandatory value, then, it shall fulfil the 

rule of note 7 up to the claimed number of bearers. 
NOTE 9: Slot type shall be Double slot with MAC service IpQ. 



In addition to table 4, systems shall fulfil all the mandatory requirements for each system category (table 3) and the 
backcompatibility rule described in notes 3, 4 and 5 of table 3. 
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5.2.3 Indication of compliance with a data category 

All NG-DECT data equipment compliant with the present specification, shall broadcast the supported number of 
bearers and the supported category type, if any, using the Terminal capability and the fixed part capabilities information 
elements in the way described in the present document. 

NOTE: Manufacturers may indicate the category type and the maximum number of supported bearers in their 
documentation with the text "DPRS Cat n x+x/y+1" where n is the maximum category supported and x 
and y the maximum number of bearers supported in symmetric and asymmetric configurations. 



Profile specific requirements 



6.1 



General 



The tables listed in this clause define the status of all protocol elements (i.e. features, services, and procedures), which 
can be: mandatory, optional, conditional under the provision of another protocol element, outside the scope of the 
present document, or not applicable. The status is identified by the status column designations defined in clause 3.2, and 
is described separately for FT and PT. 

All optional elements shall be process mandatory according to the procedures described in the present document. 

Protocol elements defined as mandatory, optional or conditional in this clause are further defined in the referenced 
DECT specification, or, if needed, in clause 7 of the present document. 

New Generation DECT; part 2: support of transparent packet data is defined as an application specific access profile of 
DPRS [16]. All procedures not specific to the new generation DECT are referenced to their original description in 
EN 301 649 (DPRS) [16]. 

The requirements of EN 301 649 [16] relevant for Class 2 equipment shall apply with the modifications stated, if 
needed, in clause 7 of the present document. 

The encapsulation of external data protocol shall be done as stated in EN 301 649 [16], annex B.4 (Ethernet 
Interworking) or annex B.6 (IP Interworking). 

In any case, the requirements of EN 300 176-1 [9], EN 300 176-2 [10] and any of the harmonized standard 
EN 301 406 [11] shall be met by all equipment conforming to the present document. 

The requirements tables in the following clauses are derived from the EN 301 649 [16]. In the service to procedure and 
feature to procedure mapping tables, the status of each particular item is explicitly stated only when it constitutes a 
change to the status indicated in EN 301 649 [16]. 

6.2 General class/service/interworking support 
6.2.1 Class/service support 

The following service classes and end-user services shall be supported by New Generation DECT data equipment. 

Table 5: General class and service support 



Item 


Name of service 


Reference Support status | 


PT 


FT 


DPRS-G.1 


DPRS Class 1 


4.3.8 [16] 


1 


1 


DPRS-G.2 


DPRS Class 2 


4.3.8 [16] 


M 


M 


DPRS-G.3 


Frame Relay (FREL) 


4.3.9 and annex B [16] 


M 


M 


DPRS-G.4 


Character stream 


4.3.9 and annexe [16] 


1 


1 


NOTE: The reference column refers to the relevant clause in the referenced document. 
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6.2.2 Protocol interworking support 

The following protocol interworking modes shall be supported by New Generation DECT data equipment. 

Table 6: General service/interworking support 





Status 


Service 


Interworking 


Reference 


PT 


FT 


DPRS-G.3, Frame Relay (FREL) 




4.3.9 and annex B [16] 


M 


M 




DPRS-1.1, Ethernet 


4.3.9 and B.4 [16] 


M 


M 




DPRS-1.2, Token Ring 


4.3.9 and B.5 [16] 


1 


1 




DPRS-1.3, IP 


4.3.9 and B.6 [16] 










DPRS-1.4, PPP 


4.3.9 and B.7 [16] 


1 


1 




DPRS-1.5, Generic media encapsulation 


4.3.9 and B.8 [16] 


1 


1 


DPRS-G.4, Character stream 




4.3.9 and annexe [16] 


1 


1 




DPRS-1.6, V.24 


4.3.9 and C.4 [16] 


1 


1 


NOTE: The reference column refers to the relevant clause in the referenced document. 



6.3 



Void 



6.4 Physical layer (PHL) requirements 
6.4.1 Physical layer (PHL) services 

New Generation DECT data devices shall support the following Physical layer (PHL) services. 

Table 7: Physical layer service support 



Item 


Name of service 


Reference 


Support status 


PT 


FT 


DPRS-P.1 


GFSK modulation 


4.3.1 [16] 


M 


M 


DPRS-P.2 


71/2 DBPSK modulation 


4.3.1 [16] 






DPRS-P.3 


71/4 OBPSK modulation 


4.3.1 [16] 






DPRS-P.4 


71/8 D8PSK modulation 


4.3.1 [16] 






DPRS-P.5 


16 QAIVI modulation 


4.3.1 [16] 






DPRS-P.6 


64 QAIVI modulation 


4.3.1 [16] 






DPRS-P.13 


Physical Packet P32 


4.3.1 [16] 






DPRS-P.14 


Physical Packet P64 


4.3.1 [16] 


M 


M 


DPRS-P.15 


Physical Packet P67 


4.3.1 [16] 








DPRS-P.16 


Physical Packet P80 


4.3.1 [16] 


C71 


C71 


DPRS-P.17 


General PHL 


4.3.1 [16] 


M 


M 


DPRS-P.18 


Fast hopping radio 


4.3.1 [16] 








C71 : IF NG-DEGT-Gat.3 THEN M ELSE 0. 


NOTE: The reference column refers to the relevant clause in the referenced document. 
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6.4.2 Modulation schemes 

The following modulation schemes defined by EN 300 175-2 [2], annex D shall be supported. 

Table 8: Allowed combinations of modulation schemes 



Item 


Modulation 
scheme 


S-field 


A-field 


B + Z-field 


Support status 




1a 


GFSK 


GFSK 


GFSK 


M 




lb 


7i:/2-DBPSK 


7t/2-DBPSK 


7t/2-DBPSK 






2 


7t/2-DBPSK 


7i:/2-DBPSK 


7i:/4-DQPSK 






3 


7t/2-DBPSK 


7i:/2-DBPSK 


7t/8-D8PSK 






5 


7i:/2-DBPSK 


7i:/2-DBPSK 


16 QAM 






6 


7t/2-DBPSK 


7i:/2-DBPSK 


64 QAM 





6.4.3 PHL service to procedure mapping 

The PHL service to procedure mapping of EN 301 649 [16], clause 5.3 shall apply. 

6.5 MAC layer requirements 
6.5.1 MAC layer services 

New Generation DECT data devices shall support the following MAC layer services: 

Table 9: IVIAC service support 



Item 


Name of service 


Reference 


Support status 


PT 


FT 


DPRS-M.1 


General 


4.3.2 [16] 


M 


M 


DPRS-M.2 


Non continuous broadcast 


4.3.2 [16] 


Q 


Q 


DPRS-M.3 


Continuous broadcast 


4.3.2 [16] 


M 


M 


DPRS-M.4 


Paging broadcast 


4.3.2 [16] 


M 


M 


DPRS-M.5 


Advanced connections 


4.3.2 [16] 


M 


M 


DPRS-M.6 


lp_error_detection 


4.3.2 [16] 


M 


M 


DPRS-M.7 


lp_error_correction 


4.3.2 [16] 








DPRS-M.8 


U-plane point-to-multipoint service 


4.3.2 [16] 








DPRS-M.9 


Gg higher layer signalling 


4.3.2 [16] 


M 


M 


DPRS-M.1 


Op higher layer signalling 


4.3.2 [16] 








DPRS-M.1 1 


Encryption activation 


4.3.2 [16] 


M 


M 


DPRS-M.12 


Encryption deactivation 


4.3.2 [16] 


C93 


C93 


DPRS-M.1 3 


Quality control 


4.3.2 [16] 


M 


M 


DPRS-M.14 


Physical channel selection 


4.3.2 [16] 


M 


M 


DPRS-M.1 5 


SARI support 


4.3.2 [16] 


M 





DPRS-M.1 6 


DPRS Bearer handover 


4.3.2 [16] 


M 


M 


DPRS-M.1 8 


Connection handover 


4.3.2 [16] 








DPRS-M.1 9 


Gp channel 


4.3.2 [16] 


C97 


C97 
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Item 


Name of service 


Reference 


Support status 


PT 


FT 


DPRS-M.20 


lpQ_error_detection 


4.3.2 [16] 


C94 


C94 


DPRS-M.21 


lpQ_error_correction 


4.3.2 [16] 








DPRS-M.22 


lp_encoded protected 


4.3.2 [16] 


1 


1 


DPRS-M.23 


Ipp channel 


4.3.2 [16] 


C97 


C97 


DPRS-M.24 


Full slot 


4.3.2 [16] 


1 


1 


DPRS-M.25 


Long slot 640 


4.3.2 [16] 


M 


M 


DPRS-M.26 


Long slot 672 


4.3.2 [16] 








DPRS-M.27 


Double slot 


4.3.2 [16] 


C94 


C94 


DPRS-M.28 


IVIultibearer connections 


4.3.2 [16] 


C97 


C97 


DPRS-M.29 


Asymmetric connections 


4.3.2 [16] 


C94 


C94 


C93: If DPRS-N.28 or DPRS-N.29 then M else 1. 

C94: Status depending on system category. See table 3. For non categorized systems THEN 0. 
C97: Status depending on system category. See table 3. For non categorized systems: IF M.29 
THENM, ELSEO. 


NOTE: The reference column refers to the relevant clause in the referenced document. 



6.5.2 MAC service to procedure mapping 

The MAC layer service to procedure mapping specified in EN 301 649 [16], clause 6.2 shall apply. 

6.6 DLC layer 

6.6.1 DLC layer services 

New Generation DECT data devices shall support the following DLC layer services. 

Table 10: DLC service status 





Status 1 


Item no. 


Name of service 


Reference 


PT 


FT 


DPRS-D.1 


LU10 Enhanced Frame RELay service (EFREL) 


4.3.3 [16] 


M 


M 


DPRS-D.2 


FUlOa 


4.3.3 [16] 


M 


M 


DPRS-D.3 


FUlOb 


4.3.3 [16] 








DPRS-D.4 


FUlOc 


4.3.3 [16] 


M 


M 


DPRS-D.5 


Data Link Service (LAPC + Lc) class A service 


4.3.3 [16] 


M 


M 


DPRS-D.6 


Data Link Service (LAPC + Lc) class U service 


4.3.3 [16] 








DPRS-D.7 


Lc Frame delimiting and sequencing service 


4.3.3(16] 


M 


M 


DPRS-D.8 


Broadcast Lb service 


4.3.3 [16] 


M 


M 


DPRS-D.9 


Inter-cell voluntary connection handover 


4.3.3 [16] 








DPRS-D.10 


Connection modification 


4.3.3 [16] 


M 


M 


DPRS-D.11 


Encryption activation 


4.3.3 [16] 


M 


M 


DPRS-D.12 


Encryption deactivation 


4.3.3 [16] 


C101 


C101 


DPRS-D.13 


Connectionless U-plane 


4.3.3 [16] 








C101 : If DPRS-N.28 or DPRS-N.29 then IVI else 1. 


NOTE: The reference column refers to the relevant clause in the referenced document. 



6.6.2 DLC service to procedure mapping 

The DLC layer service to procedure mapping specified in EN 301 649 [16], clause 7.2 shall apply. 
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6.7 NWK layer 



6.7.1 General 

The NWK layer provisions shall include the following entities: 

• Call Control (CC). 

• Mobility Management (MM). 

• Link Control Entity (LCE). 

• ConnectionLess Message Service (CLMS). 

New Generation DECT data equipment is based on DPRS Class 2 (see clause 4.3.8 [16]), and therefore requires a NWK 
layer. 

6.7.2 NWK features 

New Generation DECT data devices shall support the following NWK layer features: 

Table 1 1 : NWK features status 



Feature supported 


Features 


Status 


Item no. 


Name of feature 


Reference 


PT 


FT 


DPRS-N.1 


Outgoing call 


4.3.4 [16] 








DPRS-N.2 


Off hook 


4.3.4 [16] 


M 


M 


DPRS-N.3 


On hook (full release) 


4.3.4 [16] 


M 


M 


DPRS-N.4 


Dialled digits (basic) 


4.3.4(16] 








DPRS-N.5 


Register recall 


4.3.4(16] 








DPRS-N.6 


Go to DTMF signalling (defined tone length) 


4.3.4 [16] 








DPRS-N.7 


Pause (dialling pause) 


4.3.4 [16] 








DPRS-N.8 


Incoming call 


4.3.4 [16] 








DPRS-N.9 


Authentication of PP 


4.3.4 [16] 


M 


M 


DPRS-N.10 


Authentication of user 


4.3.4 [16] 








DPRS-N.1 1 


Location registration 


4.3.4 [16] 


M 





DPRS-N.12 


On air key allocation 


4.3.4 [16] 


M 





DPRS-N.13 


Identification of PP 


4.3.4 [16] 








DPRS-N.14 


Service class indication/assignment 


4.3.4 [16] 








DPRS-N.15 


Alerting 


4.3.4 [16] 








DPRS-N.16 


ZAP 


4.3.4 [16] 








DPRS-N.17 


Encryption activation FT initiated 


4.3.4 [16] 


M 


M 


DPRS-N.18 


Subscription registration procedure on-air 


4.3.4 [16] 


M 


M 


DPRS-N.19 


Link control 


4.3.4 [16] 


M 


M 


DPRS-N.20 


Terminate access rights FT initiated 


4.3.4 [16] 


M 





DPRS-N.21 


Partial release 


4.3.4 [16] 








DPRS-N.22 


Go to DTMF (infinite tone length) 


4.3.4(16] 








DPRS-N.23 


Go to Pulse 


4.3.4 [16] 








DPRS-N.24 


Signalling of display characters 


4.3.4(16] 








DPRS-N.25 


Display control characters 


4.3.4(16] 








DPRS-N.26 


Authentication of FT 


4.3.4 [16] 








DPRS-N.27 


Encryption activation PT initiated 


4.3.4(16] 








DPRS-N.28 


Encryption deactivation FT initiated 


4.3.4 [16] 
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Feature supported 


Features 


Status 


Item no. 


Name of feature 


Reference 


PT 


FT 


DPRS-N.29 


Encryption deactivation PT initiated 


4.3.4 f1 61 








DPRS-N.30 


Calling Line Identification Presentation (CLIP) 


4.3.4 [16] 








DPRS-N.31 


Internal call 


4.3.4 [16] 








DPRS-N.32 


Service call 


4.3.4(16] 








DPRS-N.33 


Dynamic parameters allocation 


4.3.4 [16] 


M 


M 


DPRS-N.34 


Service Negotiation 


4.3.4 [16] 


M 


M 


DPRS-N.35 


In call service change 


4.3.4 [16] 








DPRS-N.36 


NWK layer management 


4.3.4(16] 


M 


M 


DPRS-N.37 


Identity assignment 


4.3.4 [16] 








DPRS-N.38 


DECT External handover 


5.1 [28] 








DPRS-N.39 


IVlessage Waiting Indication 


5.1 [28] 








DPRS-N.40 


Detach 


5.1 [28] 








DPRS-N.41 


Periodic location registration 


5.1 [28] 








DPRS-N.42 


On-air modification of user parameters 


5.1 [28] 








NOTE: The reference column refers to the relevant clause in the referenced document. 



6.7.3 NWK features to procedures mapping 

The NWK layer feature to procedure mapping specified in EN 301 649 [16], clause 8.2 shall apply. 

6.8 Application features 
6.8.1 Application features 

New Generation DECT data devices shall support the following application features. 

Table 12: Application features status 



Feature supported 


Status 


Item no. 


Name of feature 


Reference 


PT 


FT 


DPRS-A.1 


AC bitstring mapping 


4.3.5 [16] 


M 


M 


DPRS-A.2 


Multiple subscription registration 


4.3.5 [16] 





N/A 


DPRS-A.3 


Manual entry of the PARK 


4.3.5 [16] 





N/A 


NOTE: The reference column refers to the relevant clause in the referenced document. 



6.8.2 Application features to procedures mapping 

The Application feature to procedure mapping specified in EN 301 649 [16], clause 8.4 shall apply. 



6.9 



Distributed communications 



The distributed communication mode (PP-PP communication) is not part of the present document. 

Table 13: Distributed communication requirements 



Feature supported 


Status 1 


Feature 


Name of feature 


Ref. 


PT 


FT 


DPRS-DC.1 


Distributed Communication 


4.3.6(16] 


1 


1 


NOTE: The reference column refers to the relevant clause in the referenced document. 
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6.10 Management Entity (ME) 

6.1 0.1 Management Entity (IVIE) operation modes 

In regard to the New Generation DECT data equipment, the following ME operation modes from EN 301 649 [16], 
clause 9.1 shall apply: 

Table 14: Management Entity Requirements 



Feature supported 


Status 


Feature 


Name of feature 


Ref. 


PT 


FT 


DPRS-ME.1 


Class 1 management 


4.3.7 [16] 


1 


1 


DPRS-ME.2 


Class 2 management 


4.3.7 [16] 


M 


M 


NOTE: The reference column refers to the relevant clause in the referenced document. 



6.1 0.2 Management Entity (ME) mode to procedures mapping 

In regard to the New Generation DECT data equipment, the operation mode to procedure mapping specified in 
EN 301 649 [16], clause 9.1.2 shall apply. 



7 



Profile specific procedures description 



7.1 



General 



This clause identifies differences and additions to the feature/service/procedure definitions and descriptions as specified 
in EN 301 649 [16], DPRS. 

7.2 Management Entity (ME) procedures 

No differences/additions - the procedures as specified in EN 301 649 [16], clauses 9 and A.l shall apply. 

7.3 MAC layer procedures 

No differences/additions - the procedures as specified in EN 301 649 [16], clause 10 shall apply. 

7.4 DLC layer procedures 

No differences/additions - the procedures as specified in EN 301 649 [16], clause 11 shall apply. 



7.5 NWK layer procedures 



The procedures as specified in EN 301 649 [16], clause 12 shall apply with the modifications listed in the present 
clause. 
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7.5.1 Terminal capability indication 

The contents of the <Terminal CapabiUty> information elements shall be based on the requirements of 
EN 30 1649 [16], clause 12.3. 

For the purpose of this ASAP only the status of the fields and specific values implementation that has changed is 
indicated in this clause. For the rest whatever specified in EN 301 649 [16] shall apply. 

Table 15: Values used within the «TERMINAL CAPABILITY» information element 



Information element 


Field within the 
information element 


Standard values 

within the 

field/information 

element 


Normative action/comment 


«Terminal capability» 










<ext4> 









<Profile indicator 1> 


"x 1 X X X X x"B 


OUT OF SCOPE (DPRS Stream support) 






"1 X X X X X x"B 


OPTIONAL (Asymmetric bearer) 




<ext4a> 









<Profile indicator 2> 


"x X X X X X 1 "B 


MANDATORY (DPRS FREL support) 




<ext4b> 









<Profile indicator 3> 


"x 1 X X X X x"B 


MANDATORY (Ethernet support) 






"1 x x x x X x"B 


OUT OF SCOPE (Token Ring support) 




<ext4c> 









<Profile indicator 4> 


"x X X xxx 1"B 


OPTIONAL (IP support) 






"x X X x x 1 x"B 


OUT OF SCOPE (PPP support) 






"x X X X 1 X x"B 


OUT OF SCOPE (V.24 support) 






"x X X 1 XX x"B 


OPTIONAL (Cp supported) 






"x X 1 xxx x"B 


OPTIONAL (IpQ services supported) 




< ext4d > 









< ext4e > 











"x X 1 xxx x"B 


CI 51 (E+U-type mux and channel Ipp 
basic procedures supported) 






"x 1 X X X X x"B 


OPTIONAL (Channel Ipp advanced 
procedures supported) 






"1 X X X X X x"B 


OPTIONAL (Channel SIpp supported) 




< ext4f > 


1 






<Packet data category> 


[0, 1,2,3] 


MANDATORY (NG-DECT Packet Data 
Category) 






"1 X X X X X x"B 


CI 52 (Channel Gp supported) 


C1 51 : IF DPRS-M.23 THEN MANDATORY ELSE OPTIONAL 
C152: IF DPRS-M.19 THEN MANDATORY ELSE OPTIONAL 
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7.5.2 Call resources/parameters negotiation 

The contents of the messages applicable to this procedure shall be based on the requirements of the EN 301 649 [16], 
clause 12.5. 

For the purpose of this ASAP only the status of the fields and specific values implementation that has changed is 
indicated in this clause. For the rest whatever specified in EN 301 649 [16] shall apply. 

Table 16: Values used within the {CC-SETUP} message 



Information element 


Field within the 
information element 


Standard values 

within the 

field/information 

element 


Normative action/comment 


«IWU attributes» 










<Profile> 


00001 


OUT OF SCOPE (Stream support) 






00000 


MANDATORY (FREL support) 




<Profile Subtype> 


0000 


CI 61 (Ethernet (WLAN) 






1000 


OUT OF SCOPE (Interworking to V.24 
circuits (RS232)) 






0001 


OUT OF SCOPE (ISO 8802-5 (clause B.5 )) 






0010 


CI 61 (Internet Protocol (IP) (clause B.6 
(IETF RFC 791 [19])) 






0100 


OUT OF SCOPE (Point-to-Point Protocol 
(clause B.7 (IETF RFC 1661)) 


CI 61 : One of them shall be used 



7.5.3 



IWU-attributes change 



The contents of the messages applicable to this procedure shall be based on the requirements of the EN 301 649 [16], 
clause 12.7. 

For the purpose of this ASAP only the status of the fields and specific values implementation that has changed is 
indicated in this clause. For the rest whatever specified in EN 301 649 [16] shall apply. 
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Table 17: Values used within the {CC-SERVICE-CHANGE} message 



Information element 


Field within the 
information element 


Standard values 

within the 

field/information 

element 


Normative action/comment 


«IWU attributes» 










<Profile> 


00001 


OUT OF SCOPE (Stream support) 






00000 


MANDATORY (FREL support) 




<Profile Subtype> 


0000 


C171 (Ethernet (WLAN) 






1000 


OUT OF SCOPE (Interworking to V.24 
circuits (RS232) 






0001 


OUT OF SCOPE (ISO 8802-5 
(clause B.5 )) 






0010 


C171 (Internet Protocol (IP) 
(clause B.6 (IETF RFC 791 [19])) 






0100 


OUT OF SCOPE (Point-to-Point 
Protocol (clause B.7 (IETF RFC 
1661)) 


C1 71 : One of them shall be used 



7.5.4 Collective and group ringing 

The contents of the messages applicable to this procedure shall be based on the requirements of the EN 301 649 [16], 
clause 12.13. 

For the purpose of this ASAP only the status of the fields and specific values implementation that has changed is 
indicated in this clause. For the rest whatever specified in EN 301 649 [16], shall apply. 

Table 18: Values used within the {LCE-REQUEST-PAGE} message 



Information element 


Field within the 
information element 


Standard values 

within the 

field/information 

element 


Normative action/comment 




<IWU identification> 


0001 


C181 (Ethernet) 






0010 


OUT OF SCOPE (Token Ring) 






0011 


C181 (IP) 






0100 


OUT OF SCOPE (PPP) 






0101 


OUT OF SCOPE (V.24) 


CI 81 : One of them shall be used 



7.5.5 Broadcast attributes management 



The contents of the messages applicable to this procedure shall be based on the requirements of the EN 301 649 [16], 
clause 12.16. 

For the purpose of this ASAP only the status of the fields and specific values implementation that has changed is 
indicated in this clause. For the rest whatever specified in EN 301 649 [16], shall apply. 

Table 19: Extended higher layer capabilities interpretation by the PP 



BIT Number 


Attribute 


Value 


Note 


a29 


Ethernet 


1 


MANDATORY 


a30 


Token Ring 


X 


OUT OF SCOPE 


a31 


IP 


1 


OPTIONAL 


a32 


PPP 


X 


OUT OF SCOPE 


a33 


V.24 


X 


OUT OF SCOPE 


a45 


DPRS Stream support 


X 


OUT OF SCOPE 


a46 


DPRS FREL support 


1 


MANDATORY 
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Table 20: Extended higher layer capabilities part 2 interpretation by the PP 



BIT Number 


Attribute 


Value 


Note 


< 325 " ^28 > 


NG-DECT Packet Data 
Category 


[0, 1,2,3] 


MANDATORY (NG-DECT Packet Data Category) 



7.6 Interworking requirements 

No differences/additions - the procedures as specified in EN 301 649 [16], clauses B.l to B.4 and B.6 shall apply. 

7.7 Physical layer procedures 

No differences/additions - the procedures as specified in EN 301 649 [16], clause 5 shall apply. 
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Annex A (normative): 

Amendments to other DECT specifications 

A.1 Amendments to EN 301 649 (DECT Packet Radio 
Service) 

The following amendments to EN 301 649 [16] shall apply for the purpose of the present document. 

A.1 .1 Scope (add to clause 1 of EN 301 649) 

The following text shall be added to clause 1 "Scope" of EN 301 649 [16]: 



1 Scope 



The present document includes New Generation DECT, a further development of the DECT standard introducing 
wideband speech, improved data services, new slot types and other technical enhancements. 

A.1 .2 References (add to clause 1 of EN 301 649) 

The following entries shall be added to clause 2 "References" of EN 301 649 [16]: 

[x] ETSI EN 301 406: "Digital Enhanced Cordless Telecommunications (DECT); Harmonized EN for 

Digital Enhanced Cordless Telecommunications (DECT) covering essential requirements under 
article 3.2 of the R&TTE Directive; Generic radio". 

[x] IETF RFC 2460: " Internet Protocol version 6". 

[x] ETSI EN 300 176-1: "Digital Enhanced Cordless Telecommunications (DECT); Approval test 

specification; Part 1: Radio". 

[x] ETSI EN 300 176-2: "Digital Enhanced Cordless Telecommunications (DECT); Approval test 

specification; Part 2: Speech". 

The complete clause 2 of EN 301 649 [16] shall be as follows: 

2 References 

[1] ETSI EN 300 175-1: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 1: Overview". 

[2] ETSI EN 300 175-2: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 2: Physical layer (PHL)". 

[3] ETSI EN 300 175-3: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 3: Medium Access Control (MAC) layer". 

[4] ETSI EN 300 175-4: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 4: Data Link Control (DEC) layer". 

[5] ETSI EN 300 175-5: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 5: Network (NWK) layer". 

[6] ETSI EN 300 175-6: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 6: Identities and addressing". 
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[7] ETSI EN 300 175-7: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 7: Security features". 

[8] ETSI EN 300 444: "Digital Enhanced Cordless Telecommunications (DECT); Generic Access 

Profile (GAP)". 

[9] ETSI EN 300 824: "Digital Enhanced Cordless Telecommunications (DECT); Cordless Terminal 

Mobility (CTM); CTM Access Profile (CAP)". 

[10] ISO/IEC 8802-3: "Information technology - Telecommunications and information exchange 

between systems - Local and metropolitan area networks - Specific requirements - 
Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and 
physical layer specifications". 

[11] ISO/IEC 8802-5: "Information technology - Telecommunications and information exchange 

between systems - Local and metropolitan area networks - Specific requirements - 
Part 5: Token ring access method and physical layer specifications". 

[12] IETF RFC 791 (1981): "Internet Protocol". 

[13] IETF RFC 1661 (1994): "The Point-to-Point Protocol (PPP)". 

[14] IETF RFC 1662 (1994): "PPP in HDLC-like Framing". 

[15] ITU-T Recommendation V.24 (2000): "List of definitions for interchange circuits between data 

terminal equipment (DTE) and data circuit-terminating equipment (DCE)". 

[16] ISO/IEC 9646-7: "Information technology - Open Systems Interconnection - Conformance testing 

methodology and framework - Part 7: Implementation Conformance Statements". 

[17] IETF RFC 768: "User Datagram Protocol". 

[18] IETF RFC 793: "Transmission Control Protocol". 

[19] IETF RFC 1939: "Post Office Protocol - Version 3". 

[20] IETF RFC 2045: "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet 

Message Bodies". 

[21] IETF RFC 2046: "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types". 

[22] IETF RFC 2049: "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance 

Criteria and Examples". 

[23] IETF RFC 2326: "Real Time Streaming Protocol (RTSP)". 

[24] IETF RFC 2616: "Hypertext Transfer Protocol - HTTP/1. 1". 

[25] IETF RFC 2633: "S/MIME Version 3 Message Specification". 

[26] IETF RFC 2821 : "Simple Mail Transfer Protocol". 

[27] IETF RFC 2822: "Internet Message Format". 

[28] IETF RFC 3261: "SIP: Session Initiation Protocol". 

[29] IETF RFC 3232: "Assigned Numbers". 

[30] IETF RFC 3550: "RTP: A Transport Protocol for Real-Time Applications". 

[31] ETSI EN 301 406: "Digital Enhanced Cordless Telecommunications (DECT); Harmonized EN for 

Digital Enhanced Cordless Telecommunications (DECT) covering essential requirements under 
article 3.2 of the R&TTE Directive; Generic radio". 

[32] ETSI TS 102 342: "Digital Enhanced Cordless Telecommunications (DECT); Cordless 

Multimedia Communication System; Open Data Access Profile (ODAP)". 
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[33] ETSI TS 102 265: "Digital Enhanced Cordless Telecommunications (DECT); DECT Access to IP 

networks". 

[34] IETF RFC 2460 (1998): " Internet Protocol version 6". 

[35] ETSI EN 300 176-1 : "Digital Enhanced Cordless Telecommunications (DECT); Approval test 

specification; Part 1: Radio". 

[36] ETSI EN 300 176-2: "Digital Enhanced Cordless Telecommunications (DECT); Approval test 

specification; Part 2: Speech". 

A.1 .3 Definitions and abbreviations 

A.1 .3.1 Definitions (add to clause 3.1 of EN 301 649) 

The following entry shall be added to clause 3.1 of EN 301 649 [16]: 

3.1 Definitions 

New Generation DECT: a further development of the DECT standard introducing wideband speech, improved data 
services, new slot types and other technical enhancements. 

A.1 .3.2 Definitions (modify clause 3.1 of EN 301 649) 

The following entry in clause 3.1 of EN 301 649 [16] shall be modified as follows: 

Virtual Circuit: any packet-mode user connection able to transport the user packet data protocol. Each Virtual Circuit 
provides an independent and isolated context for each subscriber data session. 

NOTE: A Virtual Circuit in DPRS is equivalent to what in GPRS is called PDP context. 

A.1 .3.3 Abbreviations (add to clause 3.3 of EN 301 649) 

The following entry shall be added to clause 3.3 of EN 301 649 [16]: 

3.3 Abbreviations 

FTP File Transfer Protocol 

DHCP Dynamic Host Configuration Protocol 

LLC Logical Link Control 

PSTN Pubhc Switched Telephone Network 

PABX Private Automatic Branch eXchange 

NAT Network Address Translator 

PAT Port Address Translator 

^^PF Higher layer connectionless channel in Eh-U mode slots 

AI/F Air InterFace 

LUlO LAP-U service 10 

NOTE: See EN 300 175-4[4]. 

FUlO Frame structure for U-plane service 10 

NOTE: See EN 300 175-4[4]. 

ARC Access Rights Class 

ARD Access Rights Details 

BCD Binary Coded Decimal 

CI Common Interface 

Eh-U Mode of the B -field E/U multiplexer carrying U-plane data and signalling 

GSM Global System Mobile 
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GPRS General Packet Radio Service 

HL Higher Layer 

HLFPI Higher Layer Fixed Part Information 

HLI Higher Layer Information 

IMS IP Multimedia Subsystem 

Ipp higher layer U-plane channel in E+U mode slots 

NG-DECT New Generation DECT 

NTP Normal Transmit Power 

PDP Packet Data Protocol 

UMTS Universal Mobile Telecommunication System 

A.1 .4 Description of services 

A.1 .4.1 Service Objectives (modify clause 4.2 of EN 301 649) 

Clause 4.2 of EN 301 649 [16] shall be modified as follows: 

4 Description of services 

4.2 Service objectives 

4.2.1 Characteristics of the DECT packet data service 

The DECT packet data service provides an efficient transparent transport of IP and upper layers with the following 
characteristics: 

Packet mode: the service provided by DECT uses only the air interface resources when there are data to be transported, 
allowing re-use of the spectrum by statistical multiplexation between multiple users and systems. 

Connection Oriented: the service provided by DECT provides controlled and isolated logical paths between 
ends -Virtual Circuits- that can be permanent or switched. The fact that DECT provides a connection-oriented service 
does not introduce any kind of restriction when transporting connectionless protocols (like IP), and provides important 
advantages regarding to the security and mobility management. It is also possible to have in the same DECT system 
several data network completely isolated between them. 

Complete mobility management: DECT provides complete mobility management (handover, roaming) like a cellular 

system. 

Security: DECT provides serious authentication and ciphering exactly as a cellular system (i.e. GSM). Ciphering is 
performed at MAC layer using dedicated Hw and does not consume application processing power. 

Asymmetric connections: DPRS makes use of the TDD characteristic of DECT to revert the transmission direction of 
the bearers, doubling the transmission speed of the system. This process is performed automatically and continuously 
by the system in order to optimize transmission speed. There is no a pre-set direction of transmission. The system could 
move from maximum speed downlink to maximum speed uplink according to the data to be transmitted. 

High Speed: DECT offers transmission speeds of up to 5 068 Mbit/s asymmetric or 2 772 Mbit/s + 2 772 Mbit/s 
symmetric with the higher modulation mode (64 QAM modulation). With the simpler GFSK modulation schema is 
possible to 845 kbit/s asymmetric or 460 kbit/s + 460 kbit/s symmetric. 

The capacities offered by DECT are similar to a cellular communication system like GPRS or UMTS. 
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Table 1 : Summary of service capabilities 



Service 


Class 1 


Class 2 


Point-to-point protected data transfer PP-FP with ARQ 


YES 


YES 


Point-to-point protected data transfer FP-PP with ARQ 


YES 


YES 


Point-to-multi-point data transfer FP-PP 


OPTIONAL 


OPTIONAL 


Point-to-point data transfer PP-PP 
(distributed communication) 


OPTIONAL 


OPTIONAL 


Authentication 


- 


YES 


Encryption 


YES 


YES 


Permanent Virtual Circuit (PVC) operation 


YES 


YES 


Virtual Call (VC) operation 


- 


YES 


Intra-cell bearer handover (see note) 


YES 


YES 


Inter-cell bearer handover (see note) 


- 


YES 


Inter-cell connection handover (for multicell systems) 


- 


OPTIONAL 


Inter-cell external handover 


- 


OPTIONAL 


NOTE: Bearer handover capability may be provided by the bearer replacement 
procedure. 



4.2.2 Performance Objectives 

The DPRS has the performance and service objectives given in the following tables. Due to the nature of radio 
transmission and packet data in general, figures could be lower in case of bad radio links, or spectrum usage 
competition from other system. 

Table 2: Performance objectives 



Performance 


Value 


Notes 


IVIaximum supported SDU size for Frame Relay services (see 
annex B) 


> 1 528 octets 


See note 1 


IVIaximum supported SDU size for character oriented services 
(see annex C) 


> 29 octets 




l\/laximum one-way delay 


Down to 50 ms 
configurable 


See note 2 


Maximum sustainable unidirectional throughput (per slot), GFSK 
2-level modulation. 


76,8 kbit/s net 


See notes 3, and 4 


Maximum sustainable unidirectional throughput (single- 
transceiver system), GFSK 2-level modulation. 


844,8 kbit/s net 


See notes 2, 3, and 4 


Maximum sustainable full bi-directional throughput (single- 
transceiver system), GFSK 2-level modulation 


460,8 kbit/s net 


See notes 2, 3, and 4 


Maximum sustainable unidirectional throughput (per slot), high- 
level modulation. 


460,8 kbit/s net 


See notes 3, 4, and 5 


Maximum sustainable unidirectional throughput (single- 
transceiver system), high-level modulation. 


5,0688 Mbit/s net 


See notes 2, 3, 4, and 5 


Maximum sustainable full bi-directional throughput (single- 
transceiver system), high level modulation 


2,7648 Mbit/s net 


See notes 2, 3, 4, and 5 


Maximum system throughput in a multi-transceiver system 


50 Mbit/s 

(10 parallel unidirectional 

connections in a DCDL- 

net) 


See notes 3, 4, and 5 


Total user bandwidth available to be shared between all 
transmitters in an area (assuming 10 frequencies), GFSK 2-level 
modulation 


9,216 Mbit/s 
(10 frequencies) 


See notes 3, and 4 


Total user bandwidth available to be shared between all 
transmitters in an area (assuming 10 frequencies), high level 
modulation 


55,296 Mbit/s 
(10 frequencies) 


See notes 3, 4, and 5 


Establishment of PT to FT physical connection (average) 


< 50 ms 


See note 2 


Establishment of FT to PT physical connection (average) 


< 50 ms 


See note 2 
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Performance 


Value 


Notes 


Undetected bit error ratio 


< 10-10 




Uncorrected bit error ratio (for air interface BER 10"-^ and delay = 
100 ms) 


<io-^ 




NOTE 1 : This is the MTU (IVIaximum Transmission Unit). This figure is compatible with the characteristics of IEEE 802.3 

and IP. 
NOTE 2: Figures could be impossible to achieve in case of competition at the air i/f between several terminals or 

systems. 
NOTE 3: Net user data rate available for high layer protocols without considering the DECT overheads. 
NOTE 4: Assuming Double Slot and IVIAC service IpQ 

NOTE 5: Using 64 QAM modulation. 

NOTE 6: Assuming the 1 frequencies available in the original DECT frequency spectrum 1 880 MHz to 1 900 MHz. 

Additional frequencies are available in several countries at 1 900 MHz to 1 920 MHz, 1 910 MHz to 

1 930 MHz, and ISM band. 



4.2.3 DPRS U-plane Services 

DPRS provides a set of U-plane protocol transport capabilities. Each of them, are defined in an annex of the 
specification, which, by historic reasons, are called "Interworking" specifications. The present edition of DPRS supports 
the following U-plane interworking modes: 

Ethernet: provides the transport of IEEE 802.3 [18] or Ethernet LAN protocols. 

Token Ring: provides the transport of IEEE 802.5, Token Ring protocol. 

IP: provides the transport of Internet Protocol v4 [12] or v6 [34] protocols. 

PPP: provides the transport of Point to Point Protocol [13] 

Generic media encapsulation: provides a generic transport for application protocols (such as SMTP, HTTP, POP, SIP, 

etc) directly transported over DECT. 

V.24: provides the emulation of a V.24 asynchronous serial line. 

The DPRS Interworking types can be classified in two classes: Frame Relay or Character stream services. 

Frame Relay Service: it is a packet transport service intended for transporting frames of any data protocol. 

Character stream service: it is packet transport service intended for transporting streams of octets. 

The Interworking type V.24 is a character stream service. All others are Frame Relay services. 

The Frame Relay service is intended for transporting frames of any data protocol. The service provides packet 
delimiters. The character stream service is intended for transporting streams of octets. It provides a Packet Assembler 
and Disassembler (PAD). 

The different Protocol interworking services are defined in annex B and C of the present document. 



4.2.4 DPRS System Categories 



DPRS systems are classified in categories depending on the data performance objectives of the system. Each category 
has specific requirements, additional to the general DPRS features and services. Table 4 defines the mandatory 
requirements for each DPRS category. 

The declaration of DPRS category is optional. It is possible to have DPRS systems not belonging to any data category. 
Such systems are called "no categorized" systems. However, the alignment to one or several DPRS categories is 
advisable in order to improve interoperability. 

The following categories are defined: 

Category 1: low-end systems providing a symmetric data rate of 50 kbit/s over a single bearer, using long slot 

Category 2: mid-end multibearer systems providing a data rate up to 500 kbit/s supporting symmetric and asymmetric 
connections 
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Category 3: high-end systems providing a data rate up to 844 kbit/s supporting symmetric and asymmetric connections 

Table 4 defines the mandatory features and services for each DPRS category. Such mandatory requirements should be 
understood as additional to the base DPRS requirements that are applicable to all DPRS systems. 

DPRS Categories are back compatible in the following way: 

• DPRS Category 2 systems shall support also Category 1 . 

• DPRS Category 3 systems shall support also Category 1 and 2. 

When FP and PP do not have the same Category, the features of the highest category supported by both sides shall be 
used. 

A.1 .4.2 Feature and service definitions (modify clause 4.3 of EN 301 649) 

Clause 4.3 of EN 301 649 [16] shall be modified as follows: 

4.3 Service and feature definitions 

4.3.1 PHL service definitions 

GFSK modulation [DPRS-P.l]: 2 level Gaussian frequency Shift Key (GFSK) modulation as defined by 

EN 300 175-2 [2] clause 5. 

Jl/2 DBPSK modulation [DPRS-P.2]: 2 level %I2 DBPSK modulation as defined by EN 300 175-2 [2] annex D.l. 

Jl/4 QBPSK modulation [DPRS-P.3]: 4 level 7t/4 DQPSK modulation as defined by EN 300 175-2 [2] annex D.2. 

31/8 D8PSK modulation [DPRS-P.4]: 8 level 7l/8 D8PSK modulation as defined by EN 300 175-2 [2] annex D.3. 

16 QAM modulation [DPRS-P.5]: 16 level QAM modulation as defined by EN 300 175-2 [2] annex D.4. 

64 QAM modulation [DPRS-P.6]: 64 level QAM modulation as defined by EN 300 175-2 [2] annex D.5. 

Physical Packet P32 [DPRS-P.13]: physical packet P32 (full slot) as defined by EN 300 175-2 [2] clause 4.4.2. 

Physical Packet P64 [DPRS-P.14]: variable capacity Physical packet POOj as defined by EN 300 175-2 [2] clause 
4.4.3, with j = 640. 

Physical Packet P67 [DPRS-P.15]: variable capacity Physical packet POOj as defined by EN 300 175-2 [2] clause 
4.4.3, with j = 672. 

Physical Packet P80 [DPRS-.P.16]: physical packet P80 (double slot) as defined by EN 300 175-2 [2] clause 4.4.4. 

General PHL [DPRS-P.18]: general physical layer procedures applicable to all DPRS terminals. 

Fast hopping radio [DPRS-P.18]: radio transceiver able to perform frequency change during the interval between two 
consecutive Physical Packets P32 (full slot) or P80 (double slot). 

4.3.2 MAC service definitions 

general [DPRS-M.l]: set of basic requirements regarding data formats, multiplexing, CRC usage, scanning and 
locking, which are prerequisites to communication between peer MAC entities. 

non-continuous broadcast [DPRS-M.2]: simplex service from FT to PT which allows PTs to acquire more 
Q channel information (i.e. TARI) and to request a new dummy bearer. 

continuous broadcast [DPRS-M.3]: simplex service from FT to PT whereby the FT maintains at least one bearer with 
continuous transmissions. The PT can use the information carried in this bearer to lock to the FT and to obtain 
knowledge about the FT (GAP-M.2). 
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paging broadcast [DPRS-M.4]: service whereby the identities of specific PTs can be broadcast by the FT. 
This service is normally used by the FT to request a specific PT to set up a link to the FT (GAP-M.3). 

advanced connection [DPRS-M.5]: service providing connection between FT and PT consisting of one or more 
duplex and zero or more double simplex bearers. Advanced connections have a common connection number, called 
Exchanged Connection Number (ECN) which is assigned by the ME. Therefore, more than one advanced connection 
may exist between a PT and one FT. The service includes the means for setting-up and releasing the required bearer(s). 

U-plane point-to-multipoint service [DPRS-M.8]: simplex service from FT to PT whereby the FT transfers a single 
SDU of U-plane data from one source point to one (or more) destination points. The service uses the Sip logical 

channel: the Sip information is protected by MAC layer error detection procedure based on 16 bit CRCS. 

Cg higher layer signalling [DPRS-M.9]: low rate connection oriented data service with ARQ using the Cg channel to 
transfer higher layer signalling data (GAP-M.5). 

Cp higher layer signalling [DPRS-M.IO]: high rate connection oriented data service with ARQ using the 
Cp channel to transfer higher layer signalling data. 

encryption activation [DPRS-M.ll]: service providing means for enabling the encryption whereby on demand all 
higher layer data is transferred across the DECT air interface in an encrypted form. Always initiated by the PT. A 
connection release automatically disables ciphering (GAP-M.7). 

encryption deactivation [DPRS-M.12]: service providing means for disabling the encryption whereby on demand all 
higher layer data is transferred across the DECT air interface in an encrypted form. A connection release automatically 
disables ciphering (GAP-M.14). 

quality control [DPRS-M.13]: provides means for monitoring and controlling the radio link quality (GAP-M.6). 

physical channel selection [DPRS-M.14]: defines the policy for the dynamic selection of a channel, caused by the fact 
that an old one has to be changed or a new one is needed. Detection of bad quality on the physical channel in use 
(i.e. due to weak signals or interference), detection of a REP with a stronger signal than the one of the own REP, 
detection of local congestion are all criteria that can be used to select the channel. 

Secondary Access Rights Identity (SARI) support [DPRS-M.15]: ability to support, in addition to the primary 
Access Rights Identity (ARI), secondary ARIs that the FT broadcasts less frequently than PARIs. These may be used to 
reflect an inter-operators agreement allowing a portable to access more than one operator or services through FT 
(GAP-M.13). 

DPRS bearer handover [DPRS-M.16]: bearer quality maintenance procedure by setting up a replacement bearer in 
the same cluster. Opposing to conventional voice channel handover, there is no the requirement of using identical LBN 
and maintaining identical data on both bearers. Furthermore, the old bearer can be released, before or after the setup of 
the new one. 

[DPRS-M.17]: void. 

connection handover [DPRS -M. 18]: connection quality maintenance by setting up replacement bearers in the same or 
a different cluster, each with identical LBN and maintaining identical data bearers with identical LBN. Subsequently the 
old bearers are released. 

Gp channel [DPRS-M.19]: fast simplex channel that is used to provide control of U-plane entities. For example it is 
used to carry acknowledgements for asymmetric connections. 

Ip_error_detection MAC service type [DPRS.M.6]: Ip_ error_detection symmetric or asymmetric service as defined 
in EN 300 175-5 [3] clauses 5.6.2.1 (type 3: Ip_ error_detection symmetric) and 5.6.2.2. (type 7: Ip_ error_detection 
asymmetric) with multi-subfield protected B-field as defined in [3] clause 6.2.1.3.3. 
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Ip_error_correction MAC service type [DPRS.M.7]: Ip_ error_correction symmetric or asymmetric service as 
defined in EN 300 175-5 [3] clauses 5.6.2.1 (type 4: Ip_ error_correction symmetric) and 5.6.2.2. (type 8: Ip_ 
error_correction asymmetric) with multi-subfield protected B-field as defined in [3] clause 6.2.1.3.3 and Mod-2- 
protected channel operation as defined by [3] clause 10.8.2. 

IpQ_error_detection MAC service type [DPRS.M.20]: lpQ_ error_detection symmetric or asymmetric service as 

defined in EN 300 175-5 [3] clauses 5.6.2.1 (type 3: lp_ error_detection symmetric) and 5.6.2.2. 

(type 7: Ip_ error_detection asymmetric) with single-subfield protected B-field as defined in [3] clause 6.2.1.3.4. 

IpQ_error_correction MAC service type [DPRS.M.21]: lpQ_ error_correction symmetric or asymmetric service as 
defined in EN 300 175-5 [3] clauses 5.6.2.1 (type 4: lp_ error_correction symmetric) and 5.6.2.2. 
(type 8: lp_ error_correction asymmetric) with single-subfield protected B-field as defined in [3] clause 6.2.1.3.4 and 
Mod-2-protected channel operation as defined by [3] clause 10.8.2. 

Ip_encoded protected MAC service type [DPRS.M.22]: lp_ encoded protected symmetric or asymmetric service as 
defined in EN 300 175-5 [3] clauses 5.6.2.1 (type 5: lp_ encoded protected symmetric), 5.6.2.2. (type 9: lp_ encoded 
protected asymmetric) and annex 1. 

Ipp channel [DPRS-M.23]: simplex channel used to transmit Ip data multiplexed in the same bearer with MAC 
signalling and Gp channel data. Also known as Eh-U mux mode. Defined in EN 300 175-3 [3] clause 10.8.4. 

Full slot [DPRS-M.24]: support of the physical packet P32 and appropriate D-field mapping according to modulation 
type (D32a for GFSK modulation). 

Long slot 640 [DPRS-M.25]: support of the physical packet POOj with j=640 and appropriate D-field mapping 
according to modulation type (D64a for GFSK modulation). 

Long slot 672 [DPRS-M.26]: support of the physical packet POOj with j=672 and appropriate D-field mapping 
according to modulation type (D67a for GFSK modulation). 

Double slot [DPRS-M.27]: support of the physical packet P80 and appropriate D-field mapping according to 
modulation type (D80a for GFSK modulation). 

Multibearer connections [DPRS-M.28]: support of multibearer connections using more than one bearer. 

Asymmetric connections [DPRS-M.29]: support of asymmetric connections using double simplex bearers, and the 
asymmetric variant of the MAC service type (types 7, 8 and 9) as defined in EN 300 175-3 [3] clause 5.6.2.2. 

4.3.3 DLC service definitions 

LUIO Enhanced Frame RELay service (EFREL) [DPRS-D.l]: an enhanced frame relay service accessed through the 
LUlO SAP. The LUIO shall operate on a generic field of user data that shall be transferred into and out of the 
DLC U-plane as a single SDU. This SDU is assumed to contain one external frame, but the operation of LUIO shall be 
independent of the actual contents of the SDU. LUIO shall provide mechanisms that offer reliable transport of the 
generic SDUs, and that preserve the SDU boundaries. 

FUlOa [DPRS-D.2]: offers a defined fixed length frame structure and buffering functions for transmission of U-plane 
data to the MAC layer (at the transmit side) or accepts data from the MAC layer (at the receiving side) on demand and 
with minimum delay. Frame type FUlOa is used for the forward path of unidirectional links. 

FUlOb [DPRS-D.3]: offers a defined fixed length frame structure and buffering functions for transmission of higher 
layer U-plane control data from the DLC to the MAC layer (at the transmit side) or accepts data from the MAC layer 
(at the receiving side) on demand and with minimum delay. Only be used for symmetrical connections using 
bi-directional links. 

FUlOc [DPRS-D.4]: offers a defined fixed length frame structure and buffering functions for transmission of higher 
layer U-plane control data from the DLC to the MAC layer (at the transmit side) or accepts data from the MAC layer 
(at the receiving side) on demand and with minimum delay. Used to carry acknowledgements or negative 
acknowledgement for connections. Frame type FUlOc is used for the backward control path of unidirectional links: it 
contains a list of receive sequence numbers for the forward link. 
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Data Link Service (LAPC + Lc) class A service [DPRS-D.5]: single frame acknowledged C-plane data link service 
providing a data link between one FT and one PT. The higher layer information is segmented (if necessary) and 
transmitted in numbered frames. The Lc service, upon which LAPC is defined, provides frame delimiting, transparency 
and frame synchronization (GAP-D.l). 

Data Link Service (LAPC + Lc) class U service [DPRS-D.6]: unacknowledged C-plane data link service providing a 
data link between one FT and one or more PTs. The higher layer information is segmented (if necessary) and 
transmitted in unnumbered frames. The Lc service, upon which LAPC is defined, provides frame delimiting, 
transparency and frame synchronization, but no error recovery is defined. 

Lc Service [DPRS-D.7]: service providing channel dependant fragmentation, recombination, frame synchronization 
and frame delimiting transparency. Fragmentation is obtained by means of dividing a LAPC data unit into more than 
one service data units for delivery to the MAC layer C logical channel, whilst recombination is obtained by means of 
joining several service units received from the MAC layer C logical channel into a LAPC data unit. Allows the LLME 
to select the logical channel for Lc operation on a frame-by-frame basis. 

broadcast Lb service [DPRS-D.8]: simplex point-to-multipoint transmission using simple fixed length DLC frames 
providing a restricted broadcast service in direction FP to PP(s) (GAP-D.3). 

intercell voluntary connection handover [DPRS-D.9]: internal handover process provided and initiated by the DLC 
layer (as a result of a particular policy, implementers dependent, application on link management. E.g. continued poor 
quality of service from the MAC layer), whereby one set of DLC entities (C-plane and U-plane) can re-route data from 
one MAC connection to a second new MAC connection not in the domain of the same cell, while maintaining the 
service provided to the NWK layer (GAP-D.5). 

connection modification [DPRS-D.IO]: service that allows the DLC to modify a connection with connection type 
"Unknown" 

encryption activation [DPRS-D.ll]: transporting the NWK layer encryption request and the cipher key to the MAC 

layer, thereby enabling the encryption process in the MAC layer (GAP-D.6). 

encryption deactivation [DPRS-D.12]: transporting the NWK layer encryption deactivation request to the MAC layer, 
thereby disabling the encryption process in the MAC layer (GAP-D.9). 

Connectionless U-plane [DPRS-D.13]: provision of data to multiple addresses using the Sip MAC channel. 

4.3.4 NWK feature definitions 

outgoing call [DPRS-N.l]: call initiated at a DECT PP (GAP-N.l). 

off-hook [DPRS-N.2]: ability to indicate the action of going off-hook, e.g. to start call set-up or accept a call 
(GAP-N.2). 

on-hook (FULL Release) [DPRS-N.3]: ability to indicate the action of going on-hook (e.g. to terminate a call) and 
fully release the radio resource (GAP-N.3). 

dialled digits (basic) [DPRS-N.4]: capability to dial digits 0-9, x, # (GAP-N.4). 

register recall [DPRS-N.5]: ability of the PP to request the invocation of the supplementary service 
"register recall" over the DECT interface and the ability of the FP to transmit the request to the local network. 
Register recall means to seize a register (with dial tone) to permit input of further digits or other action (GAP-N.5). 

go to DTMF signalling (defined tone length) [DPRS-N.6]: go to DTMF signalling with defined tone length 
(GAP-N.6). 

pause (dialling pause) [DPRS-N.7]: ability to generate or indicate a dialling pause, e.g. to await further dial tone 

(GAP-N.7). 

incoming call [DPRS-N.8]: call received at a DECT PP (GAP-N.8). 

authentication of PP [DPRS-N.9]: process by which the identity of a DECT PP is checked by the FP (GAP-N.9). 

authentication of user [DPRS-N.IO]: process by which the identity of a user of a DECT PP is checked by the FP. The 
User Personal Identification (UPI), a personal identification of to 8 digits, manually entered by the user, is used for 
user authentication (GAP-N.IO). 
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location registration [DPRS-N.ll]: facility whereby a PP can be registered with a FP or a cluster of FPs such that 
incoming calls, radio pages or messages may be routed to it (GAP-N.l 1). 

on-air key allocation [DPRS-N.12]: capability to transform Authentication Code (AC) into User Authentication Key 
(UAK) using the key allocation procedure (GAP-N.12). 

identification of PP [DPRS-N.13]: ability for the FP to request and PP to provide specific identification parameters 

(GAP-N.l 3). 

service class indication/assignment [DPRS-N.14]: assignment by the FP to PP of the service class and indication to 
the FP by the PP of the contents of its service class (GAP-N. 14). 

alerting [DPRS-N.15]: activates or deactivates alerting at the PP using any appropriate indication (GAP-N. 15). 

ZAP [DPRS-N.16]: ability first to assign and then to re-program the account data held in the PP so that access rights 
may be suspended subject to the conditions set by the service provider being met, coupled with the ability to re-program 
the account data again to reinstate access rights once these conditions have been met. One ZAP field shall be provided 
per account field. The PP has the right to authenticate the FP prior to the execution of ZAP suspend (GAP-N. 16). 

encryption activation FT initiated [DPRS-N.17]: activation of the encryption process requested by FT (GAP-N. 17). 

subscription registration procedure on-air [DPRS-N.18]: standardized procedure for loading subscription 
registration data into a PP in real time over the air-interface (GAP-N. 18). 

link control [DPRS-N.19]: ability to request, accept, maintain and release a data link for the purposes of a NWK layer 
procedure (GAP-N. 19). 

terminate access rights FT initiated [DPRS-N.20]: ability of the FP to delete a subscription in the PP (GAP-N.20). 

partial release [DPRS-N.21]: ability to release an established or in progress Call Control (CC) call whilst retaining the 
radio resource for the purpose of accessing further services (GAP-N.21). 

go to DTMF (infinite tone length) [DPRS-N.22]: go to DTMF signalling, indicating infinite DTMF tone duration 
(GAP-N.22). 

go to pulse [DPRS-N.23]: go to pulse (decadic) signalling (GAP-N.23). 

signalling of display characters [DPRS-N.24]: transmission to the PP of characters to be displayed on the user's PP 
display (if provided) (GAP-N.24). 

display control characters [DPRS-N.25]: characters sent to the PP to control the user's display in the PP (if provided). 
Such characters include cursor control, clear screen, home, flash, inverse video etc. (GAP-N. 25). 

authentication of FT [DPRS-N.26]: process by which the identity of a FP is checked by the PP (GAP-N.26). 

encryption activation PT initiated [DPRS-N.27]: activation of the encryption process suggested by PT. 
The real time start of ciphering is done in the MAC layer and is always initiated by the PT (GAP-N.27). 

encryption deactivation FT initiated [DPRS-N.28]: deactivation of the encryption process requested by FT. 
The real time stop of ciphering is done in the MAC layer and is always initiated by the PT (GAP-N. 28). 

encryption deactivation PT initiated [DPRS-N.29]: deactivation of the encryption process suggested by PT. 
The real time stop of ciphering is done in the MAC layer and is always initiated by the PT (GAP-N. 29). 

Calling Line Identification Presentation (CLIP) [DPRS-N.30]: abiUty to provide the calUng party number to the 
called party before accepting the call (GAP-N. 30). 

internal call [DPRS-N.31]: call between 2 users that does not make use of the local network resources. This is 
typically useful in residential environments (GAP-N. 31). 

service call [DPRS-N.32]: call initiated by a DECT PT for entering of FT related service and adjustment procedures in 
a transparent way. After having sent the service call indication, the PT behaves according to the rules of a normal call 
(GAP-N.32). 

Dynamic parameters allocation [DPRS-N.33]: ability to assign/negotiate DPRS protocol handling specific 
parameters. 
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Service Negotiation [DPRS-N.34]: ability to negotiate call/service parameters during call set-up. 

In call service change [DPRS-N.35]: ability to modify call/service parameters (e.g. bandwidth, IWU parameters etc.) 
while the call is maintained. 

NWK layer management [DPRS-N.36]: management of NWK layer related data (e.g. identities, location registration, 
etc.). 

Identity assignment [DPRS-N.37]: ability to assign and store different types of PT related identities. 

DECT external handover [DPRS-N.38]: external handover is the process of switching a call in progress from one 
Fixed Part (FP-1) to another Fixed Part (FP-2). This means the handover occurs between two independent systems, 
where each system has its own lower layers of protocol and has an independent set of network layer 
Service Access Points (S APs). To make external handover possible, a common management entity above the two fixed 
terminations is necessary (CAP-N.l). 

Message waiting indication [DPRS-N.39]: this feature enables a user to receive an indication of the status of a 
message server (e.g. a voice mailbox) to which the user has access (CAP-N.4). 

Detach [DPRS-N.40]: this feature enables a PT to report to the FT that the PT is not ready to receive calls (CAP-N.5). 

Enhanced location registration [DPRS-N.41]: this feature enables automatic location registration of PT at expected 
intervals of time. (CAP-N.6). 

On-air modification of user parameters [DPRS-N.42]: this feature enables the FT to modify the active subscription 
dataofthePT(CAP-N.7). 

4.3.5 Application service definitions 

AC to bitstring mapping [DPRS-A.l]: mapping of the AC into a bitstring (GAP-A.l) 

multiple subscription registration [DPRS-A.2]: ability of PP to store more than one subscription (GAP-A.2) 

manual entry of the Portable Access Rights Key (PARK) [DPRS-A.3]: ability of the PP to accept a manual entry of 
the PARK for ensuring attachment to the right FP in a physical area covered by many providers (GAP-A.3) 

4.3.6 Distributed communication 

Distributed communication [DPRS-DC.l]: ability of a DECT terminal to provide means for or assist direct 
communication between any two terminals, members of a "closed" local DECT network. Such terminals may be of type 
HyP, or, of type PP or FP (when additional specific procedures are provided) 

4.3.7 Management Entity (ME) 

Class 1 management [DPRS-ME.l]: inter and intra DECT protocol layers management of the simplified version of 
DPRS protocol requirements that does not incorporate Network layer C-plane 

Class 2 management [DPRS-ME.2]: inter and intra DECT protocol layers management of the full version of DPRS 
protocol requirements that does incorporate full C-plane 

4.3.8 Call control and Mobility Management Service Class (MMSC) 

Service class 1 [DPRS-G.l]: it is restricted service without Network layer C-plane. It excludes call set-up procedures 
and does not provide mobility management 

Service class 2 [DPRS-G.2]: it is full operational DPRS service. It offers complete C-plane DECT protocols, including 
call-set-up procedures, mobility management, service management and service negotiation 

4.3.9 U-plane Service and interworking type 

Frame relay service [DPRS-G.3]: it is a packet transport service intended for transporting frames of any data protocol. 
The service provides packet delimiters 
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Character stream service [DPRS-G.4]: a packet transport service intended for transporting streams of octets. 

NOTE: It provides a Packet Assembler and Disassembler (PAD). 

Ethernet interworking [DPRS-I.l]: provides the transport of IEEE 802.3 [18] or Ethernet LAN protocols 

Token ring [DPRS-I.2]: provides the transport of IEEE 802.5, Token Ring protocol 

IP interworking [DPRS-I.3]: provides the transport of Internet Protocol v4 [19] or v6 [34] protocols 

PPP interworking [DPRS-I.4]: provides the transport of Point to Point Protocol [13] 

Generic media encapsulation interworking [DPRS-I.5]: provides a generic transport for application protocols (such 
as SMTP, HTTP, POP, SIP, etc) directly transported over DECT 

V.24 interworking [DPRS-I.6]: provides the emulation of a V.24 asynchronous serial line 



4.3.10 DPRS system categories 



Category 1 [DPRS-Cat.l]: low-end systems providing a symmetric data rate of 50 kbit/s over a single bearer, using 
long slot 

Category 2 [DPRS-Cat.2]: mid-end multibearer systems providing a data rate up to 500 kbit/s supporting symmetric 
and asymmetric connections 

Category 3 [DPRS-Cat.3]: high-end systems providing a data rate up to 844 kbit/s supporting symmetric and 
asymmetric connections 



A.1 .4.3 General class/service/interworking support (modify clause 4.4 of 
EN 301 649) 

Clause 4.4 of EN 301 649 [16] shall be modified as follows: 

4.4 General class/service/interworking support 

Table 3: General class and service support 



Item 


Name of service 


Reference 


Support status 


PT 


FT 


DPRS-G.1 


DPRS Class 1 


4.3.8 


0.31 


0.32 


DPRS-G.2 


DPRS Class 2 


4.3.8 


0.31 


0.32 


DPRS-G.3 


Frame Relay (FREL) 


4.3.9, annex B 


0.33 


0.34 


DPRS-G.4 


Character stream 


4.3.9, annexe 


0.33 


0.34 


0.31 , 0.32, 0.33, 0.34: At least one of these services shall be supported. 


NOTE: The reference column refers to the relevant clause in the present document. 
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Table 3a: General service/interworking support 





Status 1 


Service 


Interworking 


Reference 


PT 


FT 


DPRS-G.3, Frame Relay 
(FREL) 




4.3.9, annex B 


0.41 


0.42 




DPRS-1.1, Ethernet 


4.3.9, B.4 


C.43 


C.44 




DPRS-1.2, Token Ring 


4.3.9, B.5 


C.43 


C.44 




DPRS-1.3, IP 


4.3.9, B.6 


C.43 


C.44 




DPRS-1.4, PPP 


4.3.9, B.7 


C.43 


C.44 




DPRS-1.5, Generic media encapsulation 


4.3.9, B.8 


C.43 


C.44 


DPRS-G.4, Character 
stream 




4.3.9, annexe 


0.41 


0.42 




DPRS-1.6, V.24 


4.3.9, C.4 


M 


M 


0.41 , 0.42: At least one of these Services shall be supported. 
C.43, C.44: At least one of these Interworking shall be supported. 


NOTE: The reference column refers to the relevant clause in the present document. 



A.1 .4.4 Requirements applicable to categorized systems (add to clause 4 of 
EN 301 649) 

A new clause with the following text shall be added to clause 4 of EN 301 649 [16]: 

4.5 Requirements applicable to categorized systems 

The following requirements apply to DPRS data systems declaring compliance to one or more DPRS data categories 
(see also clause 4.2.4). 

4.5.1 IVIapping between DPRS categories and features/services 

Equipment belonging to each DPRS category type shall support the features and services defined in table 4 and shall 
use these features/services when establish communication with other systems belonging to the same category. 

For features/services not listed in table 4, the status defined in clauses 5,6,7,8 and 9 shall apply: 

Table 4: Features/services supported for each DPRS system category 



DPRS Category to feature/service mapping 


Category 


DPRS Feature/Service 


Reference 


Note 


Status 1 


DPRS-Cat.1 
Category 1 systems 




4.3.10 








GFSK modulation [DPRS-P.1]: 


4.3.1 




M 


M 


Physical Packet P64 [DPRS-P.1 4]: 


4.3.1 




M 


M 


lp_error_detection IVIAC service type 
[DPRS.M.6] 


4.3.2 




M 


M 


lp_error_correction IVIAC service type 
[DPRS.M.7] 


4.3.2 










Gp channel [DPRS-M.19] 


4.3.2 




C41 


C41 


IpF channel [DPRS-M.23] 


4.3.2 




C41 


C41 


Long slot 640 [DPRS-M.25] 


4.3.2 




M 


M 


Multibearer connections [DPRS-M.28] 


4.3.2 










Asymmetric connections [DPRS-M.29] 


4.3.2 










Class 2 Management [DPRS-ME.2] 


4.3.7 


2 


M 


M 


Service Class 2 [DPRS-G.2] 


4.3.8 


2 


M 


M 
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DPRS Category to feature/service mapping 


Category 


DPRS Feature/Service 


Reference 


Note 


Status 1 


DPRS-Cat.2 
Category 2 systems 


Physical Packet P64 [DPRS-.P.14] 


4.3.1 




M 


M 


lp_error_detection IVIAC service type 
[DPRS.M.6] 


4.3.2 




M 


M 


lp_error_correction IVIAC service type 
[DPRS.M.7] 


4.3.2 










Gp channel [DPRS-M.19] 


4.3.2 




M 


M 


Ipp channel [DPRS-M.23] 


4.3.2 




M 


M 


Long slot 640 [DPRS-M.25] 


4.3.2 




M 


M 


Multibearer connections [DPRS-M.28] 


4.3.2 




M 


M 


Asymmetric connections [DPRS-M.29] 


4.3.2 




M 


M 


Class 2 Management [DPRS-ME.2] 


4.3.7 


2 


M 


M 


Service Class 2 [DPRS-G.2] 


4.3.8 


2 


M 


M 


Category 1 operation [DPRS-Cat.1] 


4.3.10,4.4 


3 


M 


M 


DPRS-Cat.3 
Category 3 systems 


GFSK modulation [DPRS-P.1] 


4.3.1 




M 


M 


Physical Packet P80 [DPRS-.P.16] 


4.3.1 




M 


M 


lpQ_error_detection MAC service type 
[DPRS.M.20] 


4.3.2 




M 


M 


lpQ_error_correction MAC service type 
[DPRS.M.21] 


4.3.2 










Gp channel [DPRS-M.19] 


4.3.2 




M 


M 


Ipp channel [DPRS-M.23] 


4.3.2 




M 


M 


Double slot [DPRS-M.27] 


4.3.2 




M 


M 


Multibearer connections [DPRS-M.28] 


4.3.2 




M 


M 


Asymmetric connections [DPRS-M.29] 


4.3.2 




M 


M 


Class 2 Management [DPRS-ME.2] 


4.3.7 


2 


M 


M 


Service Class 2 [DPRS-G.2J 


4.3.8 


2 


M 


M 


Category 1 operation [DPRS-Cat.l] 


4.3.10,4.4 


4 


M 


M 


Category 2 operation [DPRS-Cat.2] 


4.3.10,4.4 


4 


M 


M 


C41 : IF DPRS-M.29 is supported THEN M ELSE 0. 


NOTE 1 : There can be non categorized DPRS systems 

NOTE 2: All categories are based on Class 2 management and Service Class 2. 

NOTE 3: Category 2 systems shall also support all features of Category 1 systems and shall be able to interoperate 

with them. 
NOTE 4: Category 3 systems shall also support all features of Category 1 and Category 2 systems and shall be 

able to interoperate with them. 
NOTE 5: In the case where a FP and a PP do not have the same category capabilities, the initiating side should 

use the highest category supported by both sides. 
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4.5.2 Supported data rates for equipment declaring compliance to a data 
category 

Equipment belonging to each DPRS data category type shall support, at least, the following number of active slots and 
data rates described as mandatory in table 4a. They may optionally support the number of active slots and data rates 
described as optional in table 4a. 

Table 4a: Supported data rates for each system category. 



Supported data rates for each system category 


Category 


Parameter 


Notes 


Value 1 


Data rates in kbit/s 

(see notes 1 and 2) 


Corresponding number 
of bearers 


downlink 
(FT > PT) 


uplink 
(PT > FT) 


downlink 
(FT>PT) 


uplink 
(PT>FT) 


DPRS-Cat.1 
Category 1 systems 


IVIandatory supported data-rate for 
symmetric connections 


4 


51,2 


51,2 


1 


1 


DPRS-Cat.2 
Category 2 systems 


Mandatory supported data rate for 
symmetric connections 


4,5 


204,8 


204,8 


4 


4 


Optional maximum data rate for 
symmetric connections 


4,6 


307,2 


307,2 


6 


6 


Mandatory supported downlink 
data rate for asymmetric 
connections 


4,5, 
7,3 


358,4 


44,8 


7 


1 


Optional maximum downlink data 
rate for asymmetric connections 


4,6,8 


563,2 


44,8 


11 


1 


Optional maximum uplink data 
rate for asymmetric connections 


4,6,8 


44,8 


563,2 


1 


11 


DPRS-Cat.3 
Category 3 systems 


Mandatory supported data rate for 
symmetric connections 


9,5 


307,2 


307,2 


4 


4 


Optional maximum data rate for 
symmetric connections 


9,6 


460,8 


460,8 


6 


6 


Mandatory supported downlink 
data rate for asymmetric 
connections 


9,5, 
7,3 


537,6 


57,6 


7 


1 


Optional maximum downlink data 
rate for asymmetric connections 


9,6,8 


844,8 


57,6 


11 


1 


Optional maximum uplink data 
rate for asymmetric connections 


9,6,8 


57,6 


844,8 


1 


11 


NOTE 1 : Data rate indicates net data rate provided by IVIAC layer. 

NOTE 2: The value of the backward rate in asymmetric connections includes the reduction by using the Ipp 

channel due to the insertion of the "Quality control message" in all frames. 
NOTE 3: The asymmetric uplink configuration is not mandatory. 
NOTE 4: Slot type shall be Long slot (j=640) with MAC service Ip. 

NOTE 5: The system shall support all intermediate number of bearers between the minimum 1 +1 and this value. 
NOTE 6: The system may optionally support higher number of bearers than the mandatory configuration. If 

supported, the system shall support all intermediate values between 1+1 and the claimed maximum. 
NOTE 7: In asymmetric connections, the system shall support all intermediate values in the number of duplex 

bearers from 1 to the mandatory value for symmetric connections, plus all intermediate values in the 

number of double simplex bearers from 1 to the necessary to fulfil the mandatory asymmetric rate. 

However it does not need to support a higher number of bearers in total than the used in a 1+N full 

asymmetric case. 
NOTE 8: If the system claims a higher value of asymmetric bearers than the mandatory value, then, it shall fulfil the 

rule of Note 7 up to the claimed number of bearers. 
NOTE 9: Slot type shall be Double slot with IVIAC service IpQ. 



In addition to this table, systems shall fulfil all the mandatory requirements for each system category (table 3) and the 
backcompatibility rule described in notes 3, 4 and 5 of table 3. 
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4.5.3 Indication of compliance with a data category 

All DPRS data equipment compliant with the present specification, shall broadcast the supported number of bearers and 
the supported category type, if any, using the Terminal capability and the fixed part capabilities information elements in 
the way described in the present document. 

NOTE: Manufacturers may indicate the category type and the maximum number of supported bearers in their 
documentation with the text "DPRS Cat n x+x/y+1" where n is the maximum Category supported and x 
and y the maximum number of bearers supported in symmetric and asymmetric configurations. 

A.1 .5 PHL Requirements (modify clause 5 of EN 301 649) 

Clause 5 of EN 301 649 [16] shall be modified as follows: 

5 PHL requirements 

5.1 Physical layer services 

FT and FT shall support the following PHL requirements: 



Table 5: Physical layer service support 



Item 


Name of service 


Reference 


Support status 


PT 


FT 


DPRS-P.1 


GFSK modulation 


4.3.1 


051 


051 


DPRS-P.2 


71/2 DBPSK modulation 


4.3.1 


052 


052 


DPRS-P.3 


71/4 QBPSK modulation 


4.3.1 








DPRS-P.4 


71/8 DBPSK modulation 


4.3.1 








DPRS-P.5 


16 QAM modulation 


4.3.1 








DPRS-P.6 


64 QAIVI modulation 


4.3.1 








DPRS-P.13 


Physical Packet P32 


4.3.1 


055 


055 


DPRS-P.14 


Physical Packet P64 


4.3.1 


055 


055 


DPRS-P.15 


Physical Packet P67 


4.3.1 








DPRS-P.16 


Physical Packet P80 


4.3.1 


055 


055 


DPRS-P.17 


General PHL 


4.3.1 


M 


M 


DPRS-P.18 


Fast hopping radio 


4.3.1 








C51 : IF DPRS-P.2 is not supported THEN M ELSE 0. 
C52: IF DPRS-P.1 is not supported THEN M ELSE 0. 
C55: At least one should be supported. 



5.2 



IVIodulation schemes 



The following modulation schemes defined by EN 300 175-2 [2], annex D shall be supported. 
Table 5a: Allowed combinations of modulation schemes 





Modulation 
scheme 


S-field 


A-field 


B + Z-field 


Support status 




la 


GFSK 


GFSK 


GFSK 


056 




lb 


7i:/2-DBPSK 


7i:/2-DBPSK 


7t/2-DBPSK 


057 




2 


7i:/2-DBPSK 


7t/2-DBPSK 


7t/4-DQPSK 


Q 




3 


7i:/2-DBPSK 


7t/2-DBPSK 


7i:/8-D8PSK 


Q 




5 


7i:/2-DBPSK 


7t/2-DBPSK 


16 QAM 


Q 




6 


7i:/2-DBPSK 


7t/2-DBPSK 


64 QAM 


Q 


056: If 1 b is not supported mandatory, else optional. 
057: If la is not supported mandatory, else optional. 
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For the 4- and 8-level modulation option, the requirements of EN 300 175-2 [2], annex D shall apply. 

5.3 PHL service to procedure mapping 

Table 5b: PHL service to procedure mapping 





Status 1 


Service 


Procedure 


Reference 


PT 


FT 


DPRS-P.1 GFSK modulation 




4.3.1 


051 


051 




GFSK modulation 


5 [2] 


M 


M 




Modulation scheme 1a 


5.3 


M 


M 


DPRS-P.2 nl2 DBPSK modulation 




D.I [2] 


052 


052 




71/2 DBPSK modulation 


D.I [2] 


M 


M 




Modulation scheme lb 


5.3 


M 


M 


DPRS-P.3 nlA QBPSK 
modulation 




4.3.1 





Q 




71/4 QBPSK modulation 


D.2 [2] 


M 


M 




Modulation scheme 2 


5.3 


M 


M 


DPRS-P.4 n/8 D8PSK modulation 




4.3.1 





Q 




71/8 D8PSK modulation 


D.3 [2] 


M 


M 




Modulation scheme 3 


5.3 


M 


M 


DPRS-P.5 16 QAM modulation 




4.3.1 





Q 




16 QAM modulation 


D.4 [21 


M 


M 




Modulation scheme 5 


5.3 


M 


M 


DPRS-P.6 64 QAM modulation 




4.3.1 





Q 




64 QAM modulation 


D.5 [2] 


M 


M 




Modulation scheme 6 


5.3 


M 


M 


DPRS-P.1 3 Physical Packet P32 




4.3.1 


055 


055 




Physical Packet P32 


4.4.2 [2] 


M 


M 


DPRS-P.1 4 Physical Packet P64 




4.3.1 


055 


055 




Physical Packet P64 


4.4.3 [2] 


M 


M 


DPRS-P.1 5 Physical Packet P67 




4.3.1 





Q 




Physical Packet P67 


4.4.3 [2] 


M 


M 


DPRS-P.1 6 Physical Packet P80 




4.3.1 


055 


055 




Physical Packet P80 


4.4.4 [2] 


M 


M 


DPRS-P.1 7 General PHL 




4.3.1 


M 


M 




General radio requirements 


5.4.1 


M 


M 




Minimum Normal Transmit Power (NTP) 


5.4.2 


M 


M 




Radio receiver sensitivity 


5.4.3 


M 


M 




Z-field 


5.4.4 


M 


M 




Sliding collision detection 


5.4.5 


M 


M 




Physical channel availability 


5.4.6 


M 


M 




Synchronization window 


5.4.7 


M 


M 




Power Management 


5.4.8 





Q 


DPRS-P18 Fast hopping radio 




4.3.1 





Q 




Fast hopping radio 


5.4.8 


M 


M 


051 : IF DPRS-P.2 is not supported THEN M ELSE 0. 
052: IF DPRS-P.1 is not supported THEN M ELSE 0. 
055: Status defined in table 4. For non categorized systems, at least one should be supported. 


NOTE: The reference column refers to the relevant clause in the present document except otherwise noted. 



5.4 PHL layer procedures 
5.4.1 General radio requirements 

As specified in EN 300 175-2 [2], and EN 301 406 [31] (replacing TBR 006). 
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5.4.2 Minimum Normal Transmit Power (NTP) 

The nominal NTP shall be greater than 80 mW per simultaneously active transmitter as shown by the test verdict 
criteria and declaration of EN 300 176-1 [35], clause 10.2.3. 

5.4.3 Radio receiver sensitivity 

The radio receiver sensitivity shall be -86 dBm, or better. 

5.4.4 Z-field 

The Z-field shall be transmitted by RFPs and PTs. 

5.4.5 Sliding collision detection 

PT and FT shall be able to detect sliding collision on received packets. 

Minimum criteria for sliding collision are defined as S- or Z-field failure. Early sliding collision detection may be 
supported by other means e.g. signal strength measurements in the guard band. 

The Z-field is defined to have failed if the received X- and Z-fields are not identical. 

S-field failure is defined with some tolerance in order not to restrict the physical implementation of the word 
synchronization detector. 

S-field failure may be indicated if there are 1 or more bit errors in bits sl2 to s31 (errors in bits sO to si 1 shall be 
ignored). In all cases, S-field failure shall be indicated if 3 or more bit errors occur in bits sl6 to s31. 

5.4.6 Physical channel availability 

An FP shall be able to receive and transmit on all DECT frequencies fO to f9 and at least half of the slot pairs to 11. 

A PP shall be able to receive and transmit on all DECT frequencies fO to f9, and shall be able to lock on any slot 
number to 11, and receive and transmit at least on every slot pair that is not directly neighboured to the slot the PP is 
locked to, or to a slot on which a traffic bearer is active at the PP. 

5.4.7 Synchronization window 

Related to its reference timer, the PP synchronization window shall be at least +4 bits for bearers to the REP to which 
the reference timer is synchronized, and at least +10 bits for other bearers. 



5.4.8 Power management 



To fight mutual interference between data terminals operating in different local DECT networks when using for the 
transmission most of the slots from a frame, control of the transmission power is recommended. 

If transmission power control procedure is implemented, the requirements in EN 300 175-2 [36], annex E shall fully 
apply. 



5.4.9 Fast hopping radio 



The radio transceiver shall be able to perform any frequency change during the interval between two consecutive 
Physical Packets P32 (full slot) or P80 (double slot). 
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A.1 .6 MAC layer Requirements (modify clause 6 of EN 301 649) 



Clause 6 of EN 301 649 [16] shall be modified as follows: 



MAC layer requirements 



6.1 



MAC services 



Table 6: MAC service support for mobility class 1 and 2 





Item 




Name of service 


Reference 


Support status 




PT 


FT 


DPRS-M.1 


General 


4.3.2 


M 


M 


DPRS-M.2 


Non continuous broadcast 


4.3.2 


Q 


Q 


DPRS-M.3 


Continuous broadcast 


4.3.2 


M 


M 


DPRS-M.4 


Paging broadcast 


4.3.2 


M 


M 


DPRS-M.5 


Advanced connections 


4.3.2 


M 


M 


DPRS-M.6 


lp_error_detection 


4.3.2 


C64 


C64 


DPRS-M.7 


lp_error_correction 


4.3.2 


Q 


Q 


DPRS-M.8 


U-plane point-to-multipoint service 


4.3.2 


Q 


Q 


DPRS-M.9 


Cg higher layer signalling 


4.3.2 


C61 


C61 


DPRS-M 


10 


Cp higher layer signalling 


4.3.2 


C62 


C62 


DPRS-M 


11 


Encryption activation 


4.3.2 


M 


M 


DPRS-M 


12 


Encryption deactivation 


4.3.2 


C63 


C63 


DPRS-M 


13 


Quality control 


4.3.2 


M 


M 


DPRS-M 


14 


Physical channel selection 


4.3.2 


M 


M 


DPRS-M 


15 


SARI support 


4.3.2 


C61 


C62 


DPRS-M 


16 


DPRS Bearer handover 


4.3.2 


M 


M 


DPRS-M 


18 


Connection handover 


4.3.2 


Q 


Q 


DPRS-M 


19 


Gp channel 


4.3.2 


C67 


C67 


DPRS-M 


20 


lpQ_error_detection 


4.3.2 


C64 


C64 


DPRS-M 


21 


lpQ_error_correction 


4.3.2 


Q 


Q 


DPRS-M 


22 


lp_encoded protected 


4.3.2 


C65 


C65 


DPRS-M 


23 


Ipp channel 


4.3.2 


C67 


C67 


DPRS-M 


24 


Full slot 


4.3.2 


C66 


C66 


DPRS-M 


25 


Long slot 640 


4.3.2 


C66 


C66 


DPRS-M 


26 


Long slot 672 


4.3.2 


C66 


C66 


DPRS-M 


27 


Double slot 


4.3.2 


C66 


C66 


DPRS-M 


28 


Multibearer connections 


4.3.2 


C67 


C67 


DPRS-M 


29 


Asymmetric connections 


4.3.2 


C68 


C68 


C61 
C62 
C63 
C64 

C65 
C66 

C67 

C68 


IF (CLASS 1)THENI ELSE M. 

IF (CLASS 1) THEN! ELSE 0. 

If DPRS-N.28 or DPRS-N.29 then M else 1. 

Status depending on system category. See table 4. For non Categorized systems, at least 

one should be supported. 

IF 16 QAM or 64 QAM modulation THEN M ELSE Q 

Status depending on system category. See table 4. For non Categorized systems, at least 

one should be supported. 

Status depending on system category. See table 4. For non Categorized systems: IF M.29 

THENM, ELSEQ 

Status depending on system category. See table 4. For non Categorized systems THEN Q 


NOTE: The reference column refers to the relevant clause in the present document. 
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6.2 MAC service to procedure mapping 

Table 7: MAC service to procedure mapping 





Status 1 


Service 


Procedure 


Reference 


PT 


FT 


DPRS-M.1 General 




4.3.2 


M 


M 




General 


10.1 


M 


M 




A-field Multiplexer (T-MUX) 


10.21.1 


M 


M 




B-field control Multiplexer (E/U-MUX), 
basic modes 


10.21.2.1 


M 


M 


DPRS-M.2 Non continuous broadcast 




4.3.2 










Request for specific Q channel 
information 


10.2.1 










Request for a new dummy 


10.2.2 








DPRS-M.3 Continuous broadcast 




4.3.2 


M 


M 




Downlink broadcast 


10.3 


M 


M 


DPRS-IV1.4 Paging broadcast 




4.3.2 


M 


M 




Normal paging 


10.4.3, 
10.4.1, 10.4.2 


M 


M 




Fast paging 


10.4.4, 
10.4.1, 10.4.2 










Low duty cycle paging 


10.4.5, 
10.4.1, 10.4.2 










MAG paging 


10.4.6, 
10.4.1, 10.4.2 


M 


M 












DPRS-IVI.5 Advanced connection 




4.3.2 


M 


M 




Fast setup 


10.10.1.2 










idle-locked state with set-up detection 


11.1.3.2 [3] 





1 




Logical connection setup 


10.5 


M 


M 




Logical connection release 


10.6 


M 


M 




Connection modification 


10.7 


M 


M 




Single bearer Physical connection 
setup 


10.8.1 


M 


M 




Physical Connection release 


10.9 


M 


M 




Single duplex bearer setup 


10.10.1 


M 


M 




Usage of channel list messages 


10.10.1.3 


M 


M 














Unacknowledged bearer release 


10.11.1 


M 


M 




Acknowledged bearer release 


10.11.2 








DPRS-M.6 
lp_error_detection service 




4.3.2 


C64 


C64 




Type 3: lp_error_detection symmetric 
MAC service 


5.6.2.1 [3] 


M 


M 




Type 7: lp_error_detection 
asymmetric MAC service 


5.6.2.2 [3] 


C75 


C75 




Multi-subfield protected B-field 


6.2.1.3.3 [3] 


M 


M 




Q1/Q2 bit setting for: lp_ 
error detection 


10.8.1.3.2 [3] 


M 


M 




Protected 1 channel error_detect 
procedure 


10.13.1 


M 


M 


DPRS-M.7 
lp_error_correction service 




4.3.2 










Type 4: lp_ error_correction 
symmetric MAC service 


5.6.2.1 [3] 


M 


M 




Type 8: lp_error_correction 
asymmetric MAC service 


5.6.2.2 [3] 


C75 


C75 




Multi-subfield protected B-field 


6.2.1.3.3 [3] 


M 


M 




MOD-2 protected channel operation 


10.8.2 [3] 


M 


M 




Protected 1 channel error_correct 
mode 


10.13.2 


M 


M 
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Status 


Service 


Procedure 


Reference 


PT 


FT 


DPRS-M.8 U-plane point-to-multipoint 
service 




4.3.2 










Connectionless Sip mode 


10.13.3 


M 


M 


DPRS-M.9 Cg higher layer signalling 




4.3.2 


C71 


C71 




Cg channel data 


10.14.1 


M 


M 


DPRS-IVI.1 Cp higher layer signalling 




4.3.2 


C72 


C72 




Cp channel data 


10.14.2 


M 


M 




B-field control Multiplexer (E/U-MUX), 
Cp modes 


10.21.2.2 


M 


M 


DPRS-M.11 Encryption activation 




4.3.2 


M 


M 




Encryption process - initialization and 
synchronization 


10.15.1 


M 


M 




Encryption mode control 


10.15.2 


M 


M 




Encryption handover control 


10.15.3 


M 


M 


DPRS-IVI.1 2 Encryption deactivation 




4.3.2 


C73 


C73 




Encryption mode control 


10.15.2 


M 


M 


DPRS-IVI.1 3 Quality control 




4.3.2 


M 


M 




RFPI handshake 


10.16.1 


M 


M 




PT frequency correction procedure 


10.16.2 










Bearer quality report 


10.16.3 


M 


M 




Bearer quality report for asymmetric 
bearers (IVIAC-mod2-ACK) 


10.16.3.1 


C75 


C75 




Bearer and connection control 


10.16.4 










A-CRC handshake 


10.16.5 


M 


M 


DPRS-M.14 Physical channel 
selection 




4.3.2 


M 


M 




Physical channel selection 


10.17 


M 


M 


DPRS-M.15 SARI support 




4.3.2 


C71 


C72 




Downlink broadcast 


10.3.2.3 


M 


M 


DPRS-IVI.1 6 DPRS Bearer handover 




4.3.2 


M 


M 




IVIAC Bearer replacement 


10.18 


M 


M 






4.3.2 








IVIAC Bearer handover 


10.19 








DPRS-M.18 Connection handover 




4.3.2 










Advanced connection handover 


10.12 


M 


M 


DPRS-IVI.1 9 Gp channel 




4.3.2 


C67 


C67 




Gp channel transmission 


10.20.1.1 










Gp channel reception 


10.20.1.2 


M 


M 


DPRS-M.20 
lpQ_error_detection service 






C64 


C64 




Type 3: lp_error_detection symmetric 
IVIAC service 


5.6.2.1 [3] 


M 


M 




Type 7: lp_error_detection 
asymmetric IVIAC service 


5.6.2.2 [3] 


C75 


C75 




Single-subfield protected B-field 


6.2.1.3.4 [3] 


M 


M 




Q1/Q2 bit setting for: lp_ 
error detection 


10.8.1.3.2 [3] 


M 


M 




Protected 1 channel errordetect 
procedure 


10.13.1 


M 


M 


DPRS-M.21 
lpQ_error_correction service 














Type 4: lp_ error_correction 
symmetric MAC service 


5.6.2.1 [3] 


M 


M 




Type 8: lp_error_correction 
asymmetric MAC service 


5.6.2.2 [3] 


C75 


C75 




Single-subfield protected B-field 


6.2.1.3.4 [3] 


M 


M 




MOD-2 protected channel operation 


10.8.2 [3] 


M 


M 




Protected 1 channel error_correct 
mode 


10.13.2 


M 


M 
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Status 


Service 


Procedure 


Reference 


PT 


FT 


DPRS-M.22 
lp_encoded protected 




4.3.2 


C65 


C65 




Type 5: lp_ encodec protected 
symmetric MAC service 


5.6.2.1 [3] 


M 


M 




Type 9: lp_ encodec protected 
asymmetric MAC service 


5.6.2.2 [3] 


C75 


C75 




Channel coding 


annex 1.1 [3] 


M 


M 


DPRS-M.23 
Ipp channel 




4.3.2 


C67 


C67 




B-field control Multiplexer (E/U mux), 
E+U mode 


10.21.2.3 


M 


M 




Ipp channel general 


10.22.1 


M 


M 




Ipp channel advanced procedures 


10.22.2 










Ipp channel error correct procedures 


10.22.3 


C76 


C76 




SIpp channel 


10.22.4 


C77 


C77 


DPRS-M.24 
Full slot 












D-field mapping for the full slot 
structure (physical packet P32) 


6.2.1.1.2 [3] 


M 


M 




B-field mapping for the full slot 
structure (physical packet P32) 


6.2.1.3.1.2 [3] 


M 


M 


DPRS-M.25 
Long slot 640 




4.3.2 


C66 


C66 




D-field mapping for the variable slot 
structure (physical packet POOj) with 
j=640 


6.2.1.1.4 [3] 


M 


M 




B-field mapping for the half and long 
slot structure (physical packet POOj) 
with j=640 


6.2.1.3.1.3 [3] 


M 


M 




Additional procedures for Long and 
double slots 


D.2 


M 


M 


DPRS-M.26 
Long slot 672 




4.3.2 


C66 


C66 




D-field mapping for the variable slot 
structure (physical packet POOj) with 
j=672 


6.2.1.1.4 [3] 


M 


M 




B-field mapping for the half and long 
slot structure (physical packet POOj) 
with j=672 


6.2.1.3.1.3 [3] 


M 


M 




Additional procedures for Long and 
double slots 


D.2 


M 


M 


DPRS-M.27 
Double slot 




4.3.2 


C66 


C66 




D-field mapping for the double slot 
structure (physical packet P80) 


6.2.1.1.1 [3] 


M 


M 




B-field mapping for the double slot 
structure (physical packet P80) 


6.2.1.3.1.1 [3] 


M 


M 




Additional procedures for Long and 
double slots 


D.2 


M 


M 


DPRS-M.28 Multibearer connections 




4.3.2 


C67 


C67 




Multi bearer Physical connection 
setup 


10.8.2 


M 


M 




MBC Multibearer control 


new 


M 


M 
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Status 


Service 


Procedure 


Reference 


PT 


FT 


DPRS-M.29 Asymmetric connections 




4.3.2 


C68 


C68 




Double simplex bearers 


10.10.2 


M 


M 




Double simplex bearer setup 


10.10.2 


M 


M 




Fast bearer release 


10.11.3 


M 


M 




Unacknowledged double simplex 
bearer release 


10.11.1 


M 


M 




Acknowledged double simplex bearer 
release 


10.11.2 








C71 
C72 
C73 
C74 
C75 
C76 
C77 


IF (CLASS 1)THENI ELSE M. 

IF (CLASS 1) THEN! ELSE 0. 

If DPRS-N.28 or DPRS-N.29 then M else 1. 

If (4 - or 8 - level modulation scheme) then IVI else 1. 

If DPRS-M.29 THEM M ELSE 1. 

If DPRS-M.7 OR DPRS-M.21 THEM M ELSE 1. 

If DPRS-M.8 THEM ELSE 1. 


NOTE: The reference column refers to the relevant clause in the present or in the referenced document. 



A.1 .7 DLC layer Requirements (modify clause 7 of EN 301 649) 



Clause 7 of EN 301 649 [16] shall be modified as follows: 



DLC-layer requirements 



7.1 



DLC services 



Table 8: DLC service status 





Status 


Item no. 


Name of service 


Reference 


PT 


FT 


DPRS-D.1 


LU10 Enhanced Frame RELay service (EFREL) 


4.3.3 


M 


M 


DPRS-D.2 


FUlOa 


4.3.3 


M 


M 


DPRS-D.3 


FUlOb 


4.3.3 








DPRS-D.4 


FUlOc 


4.3.3 


M 


M 


DPRS-D.5 


Data Link Service (LAPC + Lc) class A service 


4.3.3 


M 


M 


DPRS-D.6 


Data Link Service (LAPC + Lc) class U service 


4.3.3 








DPRS-D.7 


Lc Frame delimiting and sequencing service 


4.3.3 


M 


M 


DPRS-D.8 


Broadcast Lb service 


4.3.3 


M 


M 


DPRS-D.9 


Inter-cell voluntary connection handover 


4.3.3 








DPRS-D.10 


Connection modification 


4.3.3 


M 


M 


DPRS-D.1 1 


Encryption activation 


4.3.3 


M 


M 


DPRS-D.12 


Encryption deactivation 


4.3.3 


C81 


C81 


DPRS-D.13 


Connectionless U-plane 


4.3.3 


C82 


C82 


C81 : If DPRS-N.28 or DPRS-N.29 then M else 1. 
C82: If (Ethemet OR Token ring) THEN ELSE 1. 


NOTE: The reference column refers to the relevant clause in the present document. 
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7.2 DLC feature to procedure mapping 

Table 9: DLC service to procedure mapping 





Status 1 


Service 


Procedure 


Reference 


PT 


FT 


DPRS-D.1 LU10 Enhanced Frame 
RELay service (EFREL) 




4.3.3 


M 


M 




U-plane transmission class 2 


11.1.2 


M 


M 


DPRS-D.2FU10a 




4.3.3 


M 


M 




FU1 Oa frame operation 


11.2.1 


M 


M 


DPRS-D.3FU10b 




4.3.3 










FU1 Ob frame operation 


11.2.2 


M 


M 


DPRS-D.4FU10C 




4.3.3 


M 


M 




FU1 Oc frame operation 


11.2.3 


M 


M 




Insertion in FU1 Oa frames of the opposite 
link 


11.2.3.1 


M 


M 


DPRS-D.5 Data Link Service 
(LAPC + Lc) class A service 




4.3.3 


M 


M 




Class A link establishment 


11.3.1 


M 


M 




Class A acknowledged information transfer 


11.3.2 


M 


M 




Class A link release 


11.3.3 


M 


M 




Class A link re-establishment 


11.3.4 


M 


M 


DPRS-D.6 Data Link Service 
(LAPC + Lc) class U service 




4.3.3 










Class U use of LLN for unacknowledged 
information transfer 


11.4.1 


M 


M 




Class U link establishment 


11.4.2 


M 


M 




Class U unacknowledged information 
transfer 


11.4.3 


M 


M 




Class U unacknowledged release 


11.4.4 


M 


M 


DPRS-D.7 Lc Frame delimiting 
and sequencing service 




4.3.3 


M 


M 




Cg channel fragmentation and 
recombination 


11.5.1 


M 


M 




Cp channel fragmentation and 
recombination 


11.5.2 










Selection of logical channels (Cg and Cp) 


11.5.3 


M 


M 


DPRS-D.8 Broadcast Lb service 




4.3.3 


M 


M 




Normal operation 


11.6.1 


M 


M 




Expedited operation 


11.6.2 


C92 


C92 


DPRS-D.9 Inter-cell voluntary 
connection handover 




4.3.3 










Class A connection handover 


11.7.1 


M 


M 


DPRS-D.1 Connection 
modification 




4.3.3 


M 


M 




Connection modification 


11.8 


M 


M 


DPRS-D.11 Encryption activation 




4.3.3 


M 


M 




Encryption switching 


11.9 


M 


M 




Connection handover of ciphered 
connection 


11.9.2.2 


M 


C94 


DPRS-D.1 2 Encryption 
deactivation 




4.3.3 


C93 


C93 




Encryption switching 


11.9 


M 


M 
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Status 


Service 


Procedure 


Reference 


PT 


FT 


DPRS-D.13 Connectionless 
U-plane 




4.3.3 


C91 


C91 




FU1 Oa frame operation 


11.2.1 


M 


M 




Connectionless point-to-multipoint 
transmission 


11.10 


M 


M 


C91 
C92 
C93 
C94 


If (Ethernet OR Token ring) THEN ELSE 1. 

If DPRS-N.19 - fast paging implemented then M else 1. 

If DPRS-N.28 or DPRS-N.29 then M else 1. 

If DPRS-D.9 then M else 1 


NOTE: The reference column refers to the relevant clause in the present document. 



A.1 .8 NWK layer Requirements (modify clause 8 of EN 301 649) 

Clause 8 of EN 301 649 [16] shall be modified as follows: 

8 NWK layer requirements 

The NWK layer provisions shall include the following entities: 

• Call Control (CC); 

• Mobility Management (MM); 

• Link Control Entity (LCE); 

• Connectionless Message Service (CLMS). 

Only mobility class 2 equipment requires a NWK layer. For mobility class 1 equipment, configuration parameters shall 
be according to annex A of the present document. 

NWK layer procedures shall be as defined in EN 300 444 [8] (GAP), in EN 300 824 [9] (CAP), or when relevant, in the 
present document. 



8.1 



NWK features 



Table 10: NWK features status 



Feature supported 


Features 


Status 


Item no. 


Name of feature 


Reference 


PT 


FT 


DPRS-N.1 


Outgoing call 


4.3.4 








DPRS-N.2 


Off hook 


4.3.4 


M 


M 


DPRS-N.3 


On hook (full release) 


4.3.4 


M 


M 


DPRS-N.4 


Dialled digits (basic) 


4.3.4 








DPRS-N.5 


Register recall 


4.3.4 








DPRS-N.6 


Go to DTMF signalling (defined tone length) 


4.3.4 








DPRS-N.7 


Pause (dialling pause) 


4.3.4 








DPRS-N.8 


Incoming call 


4.3.4 








DPRS-N.9 


Authentication of PP 


4.3.4 


M 


M 


DPRS-N.10 


Authentication of user 


4.3.4 








DPRS-N.1 1 


Location registration 


4.3.4 


M 





DPRS-N.12 


On air key allocation 


4.3.4 


M 





DPRS-N.13 


Identification of PP 


4.3.4 








DPRS-N.14 


Service class indication/assignment 


4.3.4 








DPRS-N.15 


Alerting 


4.3.4 








DPRS-N.16 


ZAP 


4.3.4 








DPRS-N.17 


Encryption activation FT initiated 


4.3.4 


M 


M 


DPRS-N.18 


Subscription registration procedure on-air 


4.3.4 


M 


M 
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Feature supported 


Features 


Status 


Item no. 


Name of feature 


Reference 


PT 


FT 


DPRS-N.19 


Link control 


4.3.4 


M 


M 


DPRS-N.20 


Terminate access rights FT initiated 


4.3.4 


M 





DPRS-N.21 


Partial release 


4.3.4 








DPRS-N.22 


Go to DTMF (infinite tone length) 


4.3.4 








DPRS-N.23 


Go to Pulse 


4.3.4 








DPRS-N.24 


Signalling of display characters 


4.3.4 








DPRS-N.25 


Display control characters 


4.3.4 








DPRS-N.26 


Authentication of FT 


4.3.4 








DPRS-N.27 


Encryption activation PT initiated 


4.3.4 








DPRS-N.28 


Encryption deactivation FT initiated 


4.3.4 








DPRS-N.29 


Encryption deactivation PT initiated 


4.3.4 








DPRS-N.30 


Calling Line Identification Presentation (CLIP) 


4.3.4 








DPRS-N.31 


Internal call 


4.3.4 








DPRS-N.32 


Service call 


4.3.4 








DPRS-N.33 


Dynamic parameters allocation 


4.3.4 


M 


M 


DPRS-N.34 


Service Negotiation 


4.3.4 


M 


M 


DPRS-N.35 


In call service change 


4.3.4 








DPRS-N.36 


NWK layer management 


4.3.4 


M 


M 


DPRS-N.37 


Identity assignment 


4.3.4 








DPRS-N.38 


DECT External handover 


5.1 [9] 








DPRS-N.39 


Message Waiting Indication 


5.1 [91 








DPRS-N.40 


Detach 


5.1 [9] 








DPRS-N.41 


Periodic location registration 


5.1 [9] 








DPRS-N.42 


On-air modification of user parameters 


5.1 [9] 








NOTE: The reference column refers to the relevant clause in the present document, except where stated 
otherwise. 



8.2 NWK feature to procedure mapping 

Table 11 : NWK feature to procedure mapping 



Feature/Procedure mapping 


Status 1 


Feature 


Procedure 


Ref. 


PT 


FT 


DPRS-N.1, Outgoing call 




4.3.4 










Outgoing call request 


12.1 


M 


M 




Overlap sending 


8.3 [8] 


M 







Outgoing call proceeding 


8.4 [81 


M 







Outgoing call confirmation 


8.5 [8] 


M 







Outgoing call connection 


8.6 [8] 


M 


M 




Sending keypad information 


8.10 [8] 








DPRS-N.2, Off Hook 




4.3.4 


M 


M 




Outgoing call request 


12.1 


M 


M 




Incoming call connection 


8.15 [8] 


M 


M 


DPRS-N.3, On Hook (full release) 




4.3.4 


M 


M 




Normal call release 


8.7 [81 


M 


M 




Abnormal call release 


8.8 [8] 


M 


M 


DPRS-N.4, Dialled digits (basic) 




4.3.4 










Sending keypad information 


8.10 [8] 


M 


M 


DPRS-N.5, Register recall 




4.3.4 










Sending keypad information 


8.10 [8] 


M 


M 


DPRS-N.6 Go to DTMF signalling 
(defined tone length) 




4.3.4 










Sending keypad information 


8.10 [8] 


M 


M 


DPRS-N.7, Pause (dialling pause) 




4.3.4 










Sending keypad information 


8.10 [8] 


M 


M 


DPRS-N.8, Incoming call 




4.3.4 










Incoming call request 


12.2 


M 


M 




Incoming call confirmation 


8.13 [81 


M 


M 




PT alerting 


8.14 [81 


M 


M 




Incoming call connection 


8.15 [8] 


M 


M 
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Feature/Procedure mapping 


Status 


Feature 


Procedure 


Ref. 


PT 


FT 


DPRS-N.9, Authentication of tlie PP 




4.3.4 


M 


M 




Authentication of PT 


8.24 [81 


M 


M 


DPRS-N.10, Autlientication of the user 




4.3.4 










Authentication of user 


8.25 [8] 


M 


M 


DPRS-N.11, Location registration 




4.3.4 


M 







Location registration 


8.28 [8] 


M 


M 




Location update 


8.29 [8] 


M 







Terminal capability indication 


12.3 


M 


M 


DPRS-N.12, On air l<ey allocation 




4.3.4 


M 







Key allocation 


8.32 [81 


M 


M 


DPRS-N.13, Identification of PP 




4.3.4 










Identification of PT 


8.22 [8] 


M 


M 


DPRS-N.14, Service class 
indication/assignment 




4.3.4 










Obtaining access rights 


8.30 [8] 


M 


M 




Authentication of PT 


8.24 [8] 


M 


M 


DPRS-N.15, Alerting 




4.3.4 










PT alerting 


8.14 [81 


M 


M 


DPRS-N.16, ZAP 




4.3.4 










Obtaining access rights 


8.30 [81 


M 


M 




Incrementing the ZAP value 


8.26 [8] 


M 


M 




Authentication of FT 


8.23 [8] 





M 


DPRS-N.17, Encryption activation FT 
initiated 




4.3.4 


M 


M 




Cipher-switching initiated by FT 


8.33 [8] 


M 


M 




Storing the Derived Cipher Key (DCK) 


8.27 [8] 


M 


M 


DPRS-N.18, Subscription registration 
user procedure on-air 




4.3.4 


M 


M 




Obtaining access rights 


8.30 [81 


M 


M 




Terminal capability indication 


12.3 


M 


M 


DPRS-N.19, Link control 




4.3.4 


M 


M 




Indirect FT initiated link establishment 


12.11 


M 


M 




Fast Paging 


12.12 










Collective and group ringing 


12.13 










Direct FT initiated link establishment 


12.14 










Direct PT initiated link establishment 


8.36 [81 


M 


M 




Link release "normal" 


8.37 [8] 


M 


M 




Link release "abnormal" 


8.38 [8] 


M 


M 




Link release "maintain" 


8.39 [81 


1 


1 




LCE Resume Paging 


12.15 


M 


cm 


DPRS-N.20, Terminate access rights FT 
initiated 




4.3.4 


M 







FT terminating access rights 


8.31 [8] 


M 


M 




Authentication of FT 


8.23 [8] 





M 


DPRS-N.21, Partial release 




4.3.4 










Partial release 


8.9 [81 


M 


M 


DPRS-N.22, Go to DTIVIF (infinite tone 
length) 




4.3.4 










Sending keypad information 


8.10 [81 


M 


M 


DPRS-N.23, Go to Pulse 




4.3.4 










Sending keypad information 


8.10 [81 


M 


M 


DPRS-N.24, Signalling of display 
characters 




4.3.4 










Display 


8.16 [81 


M 


M 




Terminal capability indication 


12.3 


M 


M 


DPRS-N.25, Display control characters 




4.3.4 










Display 


8.16 [81 


M 


M 




Terminal capability indication 


12.3 


M 


M 


DPRS-N.26, Authentication of FT 




4.3.4 










Authentication of FT 


8.23 [8] 


M 


M 
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Feature/Procedure mapping 


Status 


Feature 


Procedure 


Ref. 


PT 


FT 


DPRS-N.27, Encryption activation PT 
initiated 




4.3.4 










Cipher-switching initiated by PT 


12.9 


M 


M 




Storing the DCK 


8.27 [8] 


M 


M 


DPRS-N.28, Encryption deactivation FT 
initiated 




4.3.4 










Cipher-switching initiated by FT 


8.33 [8] 


M 


M 


DPRS-N.29, Encryption deactivation PT 
initiated 




4.3.4 










Cipher-switching initiated by PT 


12.9 


M 


M 


DPRS-N.30, Calling Line Identification 
Presentation (CLIP) 




4.3.4 










Incoming call request 


12.2 


M 


M 


DPRS-N.31, Internal call 




4.3.4 










Internal call set-up 


8.18 [8] 


M 


M 




Internal call keypad 


12.4 








DPRS-N.32, Service call 




4.3.4 










Service call set-up 


8.20 [8] 


M 


M 




Service call keypad 


8.21 [8] 








DPRS-N.33, Dynamic parameters 
allocation 




4.3.4 


M 


M 




Dynamic parameters allocation 


12.8 


M 


M 


DPRS-N.34, Service Negotiation 




4.3.4 


M 


M 




Call Resources/Parameters negotiation 


12.5 


M 


M 


DPRS-N.35, In call service change 




4.3.4 










Bandwidth Change 


12.6 


M 


M 




IWU-attributes change 


12.7 


M 


M 


DPRS-N.36, NWK layer management 




4.3.4 


M 


M 




IVIanagement of MM procedures 


12.18 


M 


M 




Management - Location registration 
initiation 


13.2 [8] 


M 


C113 




Management - Assigned individual TPUl 


13.3 [8] 


M 


C113 




Management - PMID 


12.19 


M 


M 




Management - DCK 


13.6 [8] 


M 


M 




Management - Broadcast attributes 


12.17 [8] 


M 


M 




Management - Storage of subscription 
related data 


13.7 [8] 


M 


M 




U-plane handling 


12.17 


M 


M 




Length of NWK layer messages 


12.20 


M 


M 




Identities 


12.21 


M 


M 


DPRS-N.37, Identity Assignment 




4.3.4 










Temporary Identity Assign 


12.10 


M 


M 


DPRS-N.38, DECT External handover 




5.1 [8] 










Handover candidate indication 


9.1.1.1 [8] 


M 


M 




Handover candidate retrieval 


9.1.1.2 [8] 


M 







Target FP selection 


9.1.2 [8] 


M 


N/A 




Handover reference indication 


9.1.3.1 [8] 


M 


C112 




Handover reference retrieval 


9.1.3.2 [8] 


M 


C112 




External handover call setup 


9.1.4 [8] 


M 


M 




Ciphering procedure PT initiated 


9.1.5.1 [81 










Ciphering procedure FT initiated 


9.1.5.2 [8] 


M 


M 




U-plane handling 


9.1.6 [8] 


M 


M 


DPRS-N.39, Message Waiting Indication 




5.1 [8] 










Message waiting indication 


9.7 [81 


M 


M 


DPRS-N.40, Detach 




5.1 [81 










Detach 


9.5 [81 


M 


M 


DPRS-N.41, Periodic location registration 




5.1 [81 










Enhanced location registration 


9.6 [81 


M 


M 
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Feature/Procedure mapping 


Status 


Feature 


Procedure 


Ref. 


PT 


FT 


DPRS-N.42, On-air modification of user 
parameters 




5.1 [8] 










On-air modification of user parameters 


9.8 [8] 


M 


M 




FT authentication 


8.23 [8] 


M 


M 


C1 1 1 : If single cluster system: else IVI. 

C1 1 2: At least one of these procedures shall be supported. 

C113: If DPRS-N.11 thenMelsel. 


NOTE: The reference column refers to the relevant clause in the present document, except where stated 
otherwise. 



8.3 Application features 



Table 12: Application features status 



Feature supported 


Status 


Item no. 


Name of feature 


Reference 


PT 


FT 


DPRS-A.1 


AC bitstring mapping 


4.3.5 


M 


M 


DPRS-A.2 


Multiple subscription registration 


4.3.5 





N/A 


DPRS-A.3 


Manual entry of the PARK 


4.3.5 





N/A 


NOTE: The reference column refers to the relevant clause in the present document. 



8.4 Application feature to procedure mapping 



Table 13: Application feature to procedure mapping 



Feature/Procedure mapping 


Status 1 


Feature 


Procedure 


Ref. 


PT 


FT 


DPRS-A.1 , AC to bitstring mapping 




4.3.5 


M 


M 




AC to bitstring mapping 


14.2 [8] 


M 


M 


DPRS-A.2, Multiple subscription registration 




4.3.5 





N/A 




Subscription control 


14.1 [8] 


M 


N/A 


DPRS-A.3, Manual entry of the PARK 




4.3.5 





N/A 




Manual entry of the PARK 


14.3 [8] 


M 


N/A 


NOTE: The reference column refers to the relevant clause in the present document, except where stated 
otherwise. 



8.5 



Distributed Communications 



8.5.1 Distributed Communications features 

Table 14: Distributed Communications feature status 



Feature supported 


Status 


Item no. 


Name of feature 


Reference 


PT 


FT 


HyP 


DPRS-DC.1 


Distributed Communications 


4.3.6 








M 


NOTE: The reference column refers to the relevant clause in the present document. 
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8.6 Distributed Communications feature to procedure mapping 

Table 15: Distributed Communication feature to procedure mapping 



Feature/Procedure mapping 


Feature/Procedure 


Status 


Feature Name 


Procedure name 


Reference 


PT 


FT 


HyP 


DPRS-DC.1 




4.3.6 








M 




General Requirements 


13.2 


M 


M 


M 




HyP Identities handling 


13.3.1 


N/A 


M 


M 




IVIembership Access Rights Allocation 


13.3.2 


M 


M 


M 




Re-initialization of membership access rights 


13.3.3 


M 


M 


M 




IVIembers Data Transfer 


13.3.4 


M 


M 


M 




Presence/Absence Indication 


13.3.5 


M 


M 


M 




Bandwidth management 


13.3.6 


M 


M 


M 




Direct Link Establishment 


13.3.7 


M 


M 


M 




Indirect Link Establishment 


13.3.8 


M 


M 


M 




IVIASTER management 


13.3.9 


M 


M 


M 




Common Subscription Database management 


13.3.10 


M 


M 


M 




Handover issues 


13.3.11 


M 


M 


M 




Usage of PPs or FPs in DCDL-net 


13.5 


M 


M 


M 


NOTE: The reference column refers to the relevant clause in the present document. 



A.1 .9 IVIanagement Entity requirements (modify clause 9 of 
EN 301 649) 



Clause 9 of EN 301 649 [16] shall be modified as follows: 



9.1 



IVIanagement Entity requirements 
Introduction 



The Management Entity (ME) is responsible for management of physical resources and logical associations between 
and into the DECT protocol layers. 

9.1 .1 Management Entity (ME) operation modes 

DPRS provides two operation modes of the Management Entity (ME): Class 1 and Class 2. ME Class 1 mode shall be 
used for CC and MM Service Class 1 (clause 4.3.8) and ME Class 2 mode shall be used for CC and MM Service 
Class 2 clause (4.3.8) 

Table 16: IVIanagement Entity operation mode status 



Feature supported 


Status 


Service 


Name of feature 


Ref. 


PT 


FT 


DPRS-ME.1 


Class 1 management 


4.3.7 


CI 62 


CI 62 


DPRS-ME.2 


Class 2 management 


4.3.7 


CI 63 


CI 63 


C162: IF DPRS CC and MM Service Class 1 supported [DPRS-G.1] THEN M ELSE 1. 
CI 63: IF DPRS CC and MM Service Class 2 supported [DPRS-G.2] THEN M ELSE 1. 


NOTE: The reference column refers to the relevant clause in the present document. 
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9.1 .2 Management Entity (ME) mode to procedures mapping 

Table 17: Management Entity mode to procedures mapping 



Feature/Procedure mapping 


Status 1 


Service 


Procedure 


Reference 


PT 


FT 


DPRS-ME.1, Class 1 management 




4.3.7 


CI 72 


CI 72 




Logical Connection management 


9.4.1,9.2.2 


M 


M 




Suspend management 


9.3.1.2, 
9.3.2.2 


M 


M 




Resume management 


9.3.1.1.2, 
9.3.2.1 


M 


M 




Stay Alive 


9.4.3 


M 


M 




Dynamic Bandwidth management 


9.3.1.4, 
9.3.2.3 


C171 


C171 


DPRS-ME.2, Class 2 management 




4.3.7 


CI 73 


CI 73 




Logical Connection management 


9.4.2, 9.2.3 


M 


M 




Suspend management 


9.3.1.2, 
9.3.2.2 


M 


M 




Resume management 


9.3.1.1.2, 
9.3.2.1 


M 


M 




Stay Alive 


9.4.3 


M 


M 




Dynamic Bandwidth management 


9.3.1.4, 
9.3.2.3 


C171 


C171 


CI 71 : IF (DPRS-M.5. Multi bearer Physical connection setup) THEN IVI ELSE 1. 
CI 72: IF DPRS CC and MM Service Class 1 supported THEN M ELSE 1. 
CI 73: IF DPRS CC and MM Service Class 2 supported THEN M ELSE 1. 


NOTE: The reference column refers to the relevant clause in the present document. 



A.1.10 MAC layer Procedures 

A.1.10.1 General (modify clause 10.1 of EN 301 649) 

Clause 10.1 of EN 301 649 [16] shall be modified as follows: 

10.1 General 

1 0.1 .1 Frame and multiframe structure 

The FT and PT shall support frame and multiframe structures as defined in EN 300 175-3 [3], clause 4.2. 

10.1.2 Bit mappings 

The FT and PT shall support the D-field mappings as defined in EN 300 175-3 [3], clause 6.2.1.1 for the supported 
Physical Packets (clause 5.1, table 5) and modulation schemas (clause 5.2, table 5a). 

The FT and PT shall support the A-field mappings as defined in EN 300 175-3 [3], clause 6.2.1.2 for the supported 
modulation schemas (clause 5.2, table 5a). 

The FT and PT shall support the B-field mappings as defined in EN 300 175-3 [3], clause 6.2.1.3 for the supported 
Physical Packets (clause 5.1, table 5) and modulation schemas (clause 5.2, table 5a). 

1 0.1 .3 Multiple bitmappings rule 

All bearers in use by the PT and FT in the same connection shall be identical regarding slot type and B-field CRC 
schema. However, if the PT or FT supports multiple slots an/or B-field CRC-schemas, they can be different for different 
connections. 
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NOTE: In IpQ or Ip encodec protected MAC services, the switching to multisubfield CRC schema due to the 

insertion of E or E+U type mux is not considered for this rule and can happen on a bearer-by-bearer basis. 

10.1.4 Scrambling 

The FT and PT shall support scrambling as defined in EN 300 175-3 [3], clause 6.2.4. 

10.1.5 Error control 

The FT and PT shall support R-CRC and X-CRC generation as defined in EN 300 175-3 [3], clause 6.2.5. 

For modulation schemes la and lb as defined in clause 5.2 of the present document, FT and PT shall support 
16-Bit R-CRC as defined in EN 300 175-3 [3], clause 6.2.5.2. 

For modulation schemes 2 and 3 as defined in clause 5.2 of the present document, FP and PT shall support 32-Bit CRC 
as defined in EN 300 175-3 [3], clause 6.2.5.5. 

10.1.6 void 

10.1.7 void 

1 0.1 .8 RFP idle receiver scan sequence 

The FT shall support primary scan as defined in EN 300 175-3 [3], clause 1 1.8. 

10.1.9 PT receiver scan sequence 

The PT receive scan sequence, whenever active, shall lead the RFP primary scan by one frame, as defined in 
EN 300 175-3 [3], clause 11.9. 

If PT has blind slots, i.e. slots on which setup of bearer is not possible due to implementation limitations these shall be 
indicated during subscription and location registration to the FT as described in clause 12.3. 

NOTE: Indication for PT blind slots has been introduced to the present document after version 1.1.1. Therefore 
PTs developed before version 1.2.0 may have limitation but will not be able to indicate them to the FT. 
Therefore, a FT supporting fast setup should be aware that failure of the setup may be due to PT 
limitations which have not been announced. Some examples of possible limitations could be inability of 
the PT to receive setup on slots adjacent to the slot on which the PT is locked or currently transmitting, or 
PT is able to receive only on every second slot odd or even. In such situation the FT should repeat the 
setup on different slot expecting possible limitations. 

10.1.10 PR states and state transitions 

The procedure shall be performed as specified in EN 300 175-3 [3], clause 1 1.3.3, with the following provisions: 

• The PT shall allow fast setup (if supported) for a period of time immediately following the transition from 
Active_Locked to Idle_Locked state. The duration of this period is communicated to MAC by ME 
(see clause 9.3.1.3). 

10.1.11 Identities 

The provisions of EN 300 175-3 [3], clause 1 1 .7 and EN 300 175-6 [6] shall be implemented with respect to the 
structure and use of identities. 
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A.1 .1 0.2 Qt - FP capabilities (modify clause 1 0.3.2.2 of EN 301 649) 

Clause 10.3.2.2 of EN 301 649 [16] shall be modified as follows: 

1 0.3.2.2 Qj - FP capabilities 
1 0.3.2.2.1 Standard FP Capabilities 

The FP shall indicate its standard capabilities using the fixed part capabilities Qj message as described in 

EN 300 175-3 [3], clause 7.2.3.4, with contents as defined below. The PT shall be able to receive and understand this 

message. 

Table 22: Values used within standard FP capabilities 



MAC message 


Field within the 
message 


Standard values within 
the MAC message 


Normative action/comment 


« FP capabilities » 










<Qh> 


3 






<ai2> 


1 


Extended FP info 




<ai7> 


1 


Full slot. 




<ai9> 


[0,1] 


low duty cycle ldle_Locked mode allowed. 




<a2i> 


[0,1] 


C/L uplink, relates to Distributed 
communication. 




<a22> 


[0,1] 


C/L downlink, relates to procedure Dynamic 
Parameter Allocation, clause 12.8, Sip service 

and Distributed communication. 




<a25> 


1 


B-field set-up. 




<a26> 


[0,1] 


Cp messages, if PT supports only Cg 
messages it may ignore this value. 




< a2g > 


1 


lp_error_detect. 




<a30> 


[0,1] 


lp_error_correction, if PT supports only 
lp_error_detect it may ignore this value. 




<a3i> 


[0,1] 


Multibearer connections. 


NOTE: For the higher layer capabilities, bits < agg - 847 >, see clause 12.16. 



In case of mobility class 2, the MAC extended fixed part information message shall be used and, therefore, bit aj2 of the 
fixed part information field shall be set to 1 

1 0.3.2.2.2 Extended FP capabilities 

The FP shall indicate its extended capabilities using the Extended fixed part capabilities Qj message as described in 
EN 300 175-3 [3], clause 7.2.3.5, with contents as defined below. The PT shall be able to receive and understand this 

message. 

Table 23: Values used within extended FP capabilities 



MAC message 


Field within the 
message 


Standard values within 
the MAC message 


Normative action/comment 


« FP capabilities » 










<0h> 


4 






<a2i> 


1 


MAC suspends and resume procedure 
supported. 




< a22 > 


[0,1] 


IpQ services supported. 




<a23> 


1 


Extended FP capabilities Part 2 


NOTE: For the higher layer capabilities, bits < 835 -a47 >, see clause 12.16. 
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In case of mobility class 2, the MAC extended fixed part capability part 2, information message shall be used and, 
therefore, bit a23 of the extended FP capability field shall be set to 1 . 



1 0.3.2.2.3 Extended FP capabilities part 2 

The FP shall indicate its extended capabilities using the extended fixed part capabilities part 2 Qj message as described 
in EN 300 175-3 [3], clause 7.2.3. 11, with contents as defined below. The PT shall be able to receive and understand 
this message. 

Table 23a: Values used within extended FP capabilities part 2 



MAC message 


Field within the 
message 


Standard values within 
the MAC message 


Normative action/comment 


« FP capabilities » 










<Qh> 


C (hex) 






<ai2> 


[0,1] 


Long slot support (j = 640) 




<ai3> 


[0,1] 


Long slot support (j = 672) 




<ai4> 


[0,1] 


E+U-type mux and channel Ipp basic procedures 
supported (see note 2) 




<ai5> 


[0,1] 


channel Ipp advanced procedures supported 
(see note 2) 




<ai6> 


[0,1] 


channel SIpp supported (see note 2) 




<ai7> 


[0,1] 


channel Gp supported (see note 3) 


NOTE 1: For the higher layer capabilities, bits < a24-a47 >, see clause 12.16. 

NOTE 2: See clauses 1 0.21 .2.3 and 1 0.22 for E+U type mux and channel Ipp procedures. 

NOTE 3: This bit indicates that the FP is able to receive the Gp channel. 



A.1.10.3 PT initiated single duplex bearer setup (modify clause 10.10.1.1 of 
EN 301 649) 

Clause 10.10.1.1 of EN 301 649 [16] shall be modified as follows: 

1 0.1 0.1 .1 PT initiated single duplex bearer setup 

This procedure shall be performed as defined by EN 300 175-3 [3], clause 10.5.1.3.1. 

Optionally, a number of WAIT messages may be exchanged between "bearer_request" and "bearer_confirm" if required 
by the implementation. 

NOTE: The use of WAIT messages should be avoided since it slows down the procedure. 



PT 



FT 



BEARER.req 



WAIT 



WAIT 



BEARER.cfm 



other 



other 



Figure 5: PT initiated setup of single duplex bearer 
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A.1.10.4 FT initiated single duplex bearer setup (modify clause 10.10.1.2 of 
EN 301 649) 

Clause 10.10.1.2 of EN 301 649 [16] shall be modified as follows: 

10.10.1.2 FT initiated single duplex bearer setup 

This procedure shall be performed as defined by EN 300 175-3 [3], clause 10.5.1.3.2. 

The FT initiated connection setup is also referred to as fast setup. The only bearer-request message allowed in this case 
is the access-request. Optionally a number of WAIT messages may be exchanged between "bearer_request" and 
"bearer_confirm" if required by the implementation. 

NOTE: The use of WAIT messages should be avoided since it slows down the procedure. 



PI 



FT 



BEARER. req 



WAIT 



WAIT 



BEARER.cfm 



other 



other 



Figure 6: FT initiated setup of pilot bearer (fast setup) 

A. 1 . 1 0.5 PT initiated Single duplex bearer setup (remove from clause 1 0. 1 0.2 
of EN 301 649) 

The following note shall be removed from clause 10.10.2 of EN 301 649 [16]: 

NOTE 2: Each side has a line for the duplex bearer and a line for the double simplex bearer. All channel list 
messages should be sent at the same duplex bearer. 

A. 1 . 1 0.6 Bearer quality report (modify clause 1 0. 1 6.3 of EN 301 649) 

Clause 10.16.3 of EN 301 649 [16] shall be modified as follows: 

1 0.1 6.3 Bearer quality report 

Receiver side will send bits Ql and Q2 reporting quality of received bearers. Report shall be done in bits a3 and a^ of a 
field in the reverse bearer in case of duplex bearers. In Ip_error_correct service, the bit Q2 shall be set as defined in 
EN 300 175-3 [3], clause 10.8.2.4.1, and the bit BCK, set as defined in EN 300 175-3 [3], clause 10.8.2.4.2, shall be 
send in the place of bit Ql. 

The bit Ql shall be set as defined in EN 300 175-3 [3], clause 10.8.1.3.4. The bit Q2 shall be set as described in 

EN 300 175-3 [3], clause 10.8.1.3.3. 

FT and PT should use the information of the received bits Ql and Q2 to take the decision to perform bearer replacement 
procedures. 

FT may use the information of the Ql and Q2-bits sent by the PT, to decide whether to switch antenna or not. 
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1 0.1 6.3.1 Bearer quality report for asymmetric bearers 

For asymmetric connections, the bits Ql and Q2 reporting quality of the double simplex bearers shall be carried by 
means of the "bearer quality in an asymmetric connection" message, (EN 300 175-3 [3], clause 7.3.4.4). 

The bit Ql shall be set as defined in EN 300 175-3 [3], clause 10.8.1.3.4. The bit Q2 shall be set as described in 

EN 300 175-3 [3], clause 10.8.1.3.3. In Ip_error_correct service, the bit Q2 shall be set as defined in EN 300 175-3 [3], 

clause 10.8.2.4.1, and the bit BCK, set as defined in EN 300 175-3 [3], clause 10.8.2.4.2, shall be send in the place of 
bitQl. 

FT and PT should use the information of the received bits Ql and Q2 to take the decision to perform bearer replacement 
procedures. 

FT may use the information of the Ql and Q2-bits sent by the PT, to decide whether to switch antenna or not. 

By negotiation it is possible to avoid the insertion of the message in all frames, or to suppress the message. In this case 
the procedure described in clause 10.16.4 shall be used for quality control purposes (see note 3). 

The negotiation is performed as described in clause 12.8. 

In absence of negotiation the report shall be send in all frames. 

NOTE 1: The bearer carrying the message is called "special bearer" (see EN 300 175-3 [3], clause 5.6.2.2). 

NOTE 2: There is the possibility to send the message in more than one bearer, however the content of the message 
is to be always updated according to the time it is sent. 

NOTE 3: The suppression of the "bearer quality in an asymmetric connection" message deactivates the DECT basic 
quality feedback mechanism (bits Q1/Q2) and should be only done under very good and steady radio 
quality conditions. The alternative procedure has a slower response time and a limited control capability 
and may not handle properly the case of simultaneous loss of quality on several bearers. 

A.1 .1 0.7 Gp channel (modify clause 1 0.20 of EN 301 649) 

Clause 10.20 of EN 301 649 [16] shall be modified as follows: 

10.20 Gf channel 
10.20.1 Gf channel data 

10.20.1.1 Gf channel transmission 

The transmitter side of FT and PT shall support the Gp channel transmission as defined in EN 300 175-3 [3], 
clause 7.3.6. 

1 0.20.1 .2 Gf channel reception 

The receiver side of FT and PT shall support the of Gp channel reception, as defined in EN 300 175-3 [3], 
clause 7. 3. 6,. and shall understand the frame format FUlOc when transmitted over Gp channel. 
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A.1 .1 0.8 Time multiplexers (add to clause 1 of EN 301 649) 

A new clause with the following text shall be added to clause 10 of EN 301 649 [16]: 

10.21 Time multiplexers 

10.21.1 A-field multiplexer 

1 0.21 .1.1 Tali multiplexer (T-MUX) 

The FT and PT shall support T-MUX as defined in EN 300 175-3 [3], clause 6.2.2.1. 

1 0.21 .1 .2 A-tail identifications 

The FT and PT shall understand all A-field tail identifications (bits a^ to a2) as defined in EN 300 175-3 [3], 
clause 7.1.2. The value 101 - "escape" need not be understood. To distinguish a connectionless bearer from a 
non-connectionless bearer the Nj message send on a connectionless bearer shall carry the value "Identity information 
(Nj) on connectionless bearer" (010) and the value "Identity information (Nj)"(01 1) in all other cases. 

1 0.21 .2 B-field control multiplexer (E/U-MUX) 

1 0.21 .2.1 B-field control multiplexer (E/U-MUX), basic modes 

10.21.2.1.1 U-type multiplexer 

The FT and PT shall support U-type mode multiplexer as defined in EN 300 175-3 [3], clause 6.2.2.2. 

1 0.21 .2.1 .2 E-type multiplexer, all MAC control 

The FT and PT shall support E-type mode multiplexer as defined in EN 300 175-3 [3], clauses 6.2.2.2 and 6.2.2.3 with 
the following restriction: 

• Only the "all MAC control" mode (channels M and Gp, BA code "110"), shall be supported. 

The FT and PT shall support the E-type mode "all MAC control" as defined in EN 300 175-3 [3], clause 6.2.2.3 
(tables 6.24 to 6.33) for the supported D-field mappings (defined in clause 6.2, table 7) and modulation type (defined in 
clause 5.1, table 5). 

1 0.21 .2.1 .3 E/U-Mux priority schema 

The FT and PT shall support the priority schema as defined in EN 300 175-3 [3], clause 6.2.2.4 with the following 
restriction: 

• Ipp channel modes and Ipp segmentation control are not applicable; 

• Cp channel modes are not applicable. 

1 0.21 .2.1 .4 B-field identifications (basic) 

The FT and PT shall use and understand all B-field identifications (bits a^ to ag) as defined in EN 300 175-3 [3], 
clause 7.1.4 with the following restrictions: 

• Codes for E-mux with Cp channel ("010", "Oil", "100" and "101") are not applicable. 

• Code "110" is only understood as "E-type all MAC control". 

• Code " 1 1 1" is only understood as "no B-field". 
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1 0.21 .2.2 B-field control multiplexer (E/U-MUX), Cp modes 

1 0.21 .2.2.1 E-type multiplexer, all modes 

The FT and PT shall support E-type mode multiplexer as defined in EN 300 175-3 [3], clauses 6.2.2.2 and 6.2.2.3, 
including the modes "E-type all Cp", and "E-type not all Cp". 

The FT and PT shall support all E-type modes as defined in EN 300 175-3 [3], clause 6.2.2.3 (tables 6.24 to 6.33) for 
the supported D-field mappings (defined in clause 6.2, table 7) and modulation type (defined in clause 5.1, table 5). 

1 0.21 .2.2.3 E/U-Mux priority schema 

The FT and PT shall support the priority schema as defined in EN 300 175-3 [3], clause 6.2.2.4 with the following 
restriction: 

• Ipp channel modes and Ipp segmentation control are not applicable. 

1 0.21 .2.2.4 B-field identifications (Cp) 

The FT and PT shall use and understand all B-field identifications (bits a^ to ag) as defined in EN 300 175-3 [3], 
clause 7.1.4 with the following restrictions: 

• Code "110" is only understood as "E-type all MAC control". 

• Code " 1 1 1" is only understood as "no B-field". 

1 0.21 .2.3 B-field control multiplexer (E/U-MUX), E+U modes 

1 0.21 .2.3.2 E-i-U-type multiplexer 

The FT and PT shall support the Eh-U type multiplexer as defined in EN 300 175-3 [3], clauses 6.2.2.2 and 6.2.2.3. 

The FT and PT shall support all E-nU-type modes as defined in EN 300 175-3 [3], clause 6.2.2.3 (tables 6.24 to 6.33) for 
the supported D-field mappings (defined in clause 6.2, table 7) and modulation type (defined in clause 5.1, table 5). 

1 0.21 .2.3.3 E/U-Mux priority schema 

The FT and PT shall support the priority schema as defined in EN 300 175-3 [3], clause 6.2.2.4. 

1 0.21 .2.3.4 B-field identifications (E-fU type) 

The FT and PT shall use and understand all B-field identifications (bits a^ to ag) as defined in EN 300 175-3 [3], 
clause 7.1.4 with the following restrictions: 

• Codes for E-mux with Cp channel ("010", "Oil", "100" and "101") are only applicable if Cp channel is 
supported. 



• 



Code "111" is only used for Eh-U type mux if MAC service Ip_error_correct is used. Otherwise it means "no 
B-field". 
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A.1 .1 0.9 IpF channel (add to clause 1 of EN 301 649) 

A new clause with the following text shall be added to clause 10 of EN 301 649 [16]: 

10.22 IpF channel 

10.22.1 IpF channel general 

The FT and PT shall support the higher layer U-Plane channel in E+U type slots (Ipp ) as defined in EN 300 175-3 [3], 
clauses 5.3. 1.4 and 10.8.4. 

The FT and PT shall support the "Null or Ipp segmentation info" message as defined in EN 300 175-3 [3], clause 7.3.3, 
using and understanding the meaning of the "spare or Ipp segmentation info" field, and all NCF header codes. 

The FT and PT shall use and understand all NCF codes in the message "Gp channel data packet" as defined in 

EN 300 175-3 [3], clause 7.3.6. 

The FT and PT shall activate the Ipp channel and the Eh-U type multiplexer (see clause 10.21.2.3) as defined in 
EN 300 175-3 [3], clause 10.8.4.2. 

The FT and PT shall support the Ipp channel basic procedures as defined in EN 300 175-3 [3], clause 10.8.4.3. 1 . 

The FT and PT shall support the special case procedure as defined in EN 300 175-3 [3], clause 10.8.4.3.3, if the B-field 
mapping of the supported slot type (defined in clause 6.2, table 7) and modulation type (defined in clause 5,1, table 5), 
produces a MAC packet size (DLC PDU) not multiple of 64 bits. 

The FT and PT shall support the Ipp_error_detect operation procedures as defined in EN 300 175-3 [3], clause 10.8.4.5. 
The FT and PT shall support the backcompatibility rule as defined in EN 300 175-3 [3], clause 10.8.4.7. 

1 0.22.2 IpF channel advanced procedures 

The FT and PT shall support the Ipp channel advanced procedures as defined in EN 300 175-3 [3], clause 10.8.4.3.2. 

1 0.22.3 IpF channel error_correct procedures 

The FT and PT shall support the Ipp channel error_correct procedures as defined in EN 300 175-3 [3], clause 10.8.4.4. 

10.22.4 SIpF channel 

The FT and PT shall support the connectionless U-Plane channel in Eh-U type slots, (SIpp) as defined in 

EN 300 175-3 [3], clause 5.3.2.3. 
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A. 1.11 DLC layer procedures 

A.I .11 .1 Insertion of FUl Oc frames in FU1 Oa frames of the opposite link (add 
toclause11.2.3of EN301 649) 

A new clause with the following text shall be added to clause 11.2.3 of EN 301 649 [16]: 

1 1 .2.3.1 Insertion of FU1 Oc frames in FU1 Oa frames of the opposite link 

The FT and PT shall support the transport of FUlOc frames by insertion in the frame FUlOa of the opposite link using 
the procedure described in EN 300 175-4 [4], clause 12.11.2.1. 

The sending side can take dynamically the decision on how to transport the FUlOc frames according to traffic and 
situation of the E/U mux multiplexer of the bearers used in the connection. 

NOTE 1: As general rule, the sending side should avoid the use of Gp channel using instead the FUlOa insertion 
mechanism if there is no bearer with E/U mux in selection E or E+U due to other reason. 

NOTE 2: The FUlOa insertion mechanism is recommended in any case for FUlOc frames related to the backward 
link in an asymmetric connection (FUlOc sent in forward direction). 

NOTE 3: For FUlOc frames related to the forward link (FUlOc frames sent on backward channel), it is 

recommended the use of the Gp channel, if the backward slot (or if any of them, if there are more than 
one) is in E or E+U mux selection due to other channel (f.i. MAC control). 

A. 1.1 2 NWK layer procedures 

A.1.12.1 Terminal capability indication (modify clause 12.3 of EN 301 649) 

Clause 12.3 of EN 301 649 [16] shall be modified as follows: 



12.3 Terminal capability indication 



The procedure shall be performed as defined in EN 300 444 [8], clause 8.17. The following text together with the 
associated clauses defines the mandatory requirements with regard to the present document. 

In addition the following fields need to be supported in regard to the particular DPRS application supported, 
see annexes B and C. 
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Table 69: Values used within the « TERMINAL CAPABILITY » information element 



Information element 


Field within the 
information element 


Standard values 

within the 

field/information 

element 


Normative action/comment 


« Terminal capability » 










< ext3 > 


1,0 






< Tone capability > 


All 


DPRS does not support tone capability. 
PT shall set it according to its 
capabilities; the FT is not required to 
understand it. 




< Display Capability > 


All 


PT shall set it according to its 
capabilities; the FT is not required to 
understand it if the FT does not provide 
DECT display services. 




< Echo parameter > 




See note 3. 




< N-REJ > 




See note 3. 




< A-VOL > 




See note 3. 




< ext4 > 









< Profile indicator_1 > 


"xxxxx1x"B 


(!) - Out of scope for DPRS, need not to 
be supported. 






"x1 xxxxx"B 


DPRS Stream support (see note 1). 






"1xxxxxx"B 


Asymmetric bearer. 




< ext4a > 









< Profile indicator 2 > 


"xxxxxxV'B 


DPRS FREL support (see note 1). 




< ext4b > 









< Profile indicator 3 > 


"x1xxxxx"B 


Ethernet support (see note 2). 






"1xxxxxx"B 


Token Ring support (see note 2). 




< ext4c > 









< Profile indicator 4 > 


"xxxxxx1"B 


IP support (see note 2). 






"xxxxxl x"B 


PPP support (see note 2). 






"xxxx1xx"B 


V.24 support (see note 2). 






"xxx1xxx"B 


Cp supported. The support of the Cp is 
optional. 






"xx1xxxx"B 


IpQ services supported. Optional for 
2-level modulation scheme. 






"1xxxxxx"B 


Generic media encapsulation transport 
supported (see note 2). 




< ext4d > 





See note 5. 




< Profile indicator_5 > 


"xxxxxx 1"B 


2-level modulation scheme supported 
(B + Z field). 






"xxxxxl x"B 


4-level modulation scheme supported 
(B + Z field) - Optional. 






"x X X X 1 X x"B 


8-level modulation scheme supported 
(B + Z field) - Optional. 






"x X 1 XXX x"B 


2-level modulation scheme supported 
(Afield). 




< Control codes > 


All 


PT shall set it according to its 
capabilities; the FT is not required to 
understand it if the FT does not provide 
DECT display services or does not 
support control codes. 




< ext4e > 











"x X 1 XXX x"B 


C691 (E+U-type mux and channel Ipp 
basic procedures supported). 






"x 1 X X X X x"B 


OPTIONAL (Channel Ipp advanced 
procedures supported). 






"1 X X X X X x"B 


OPTIONAL (Channel Slpp supported). 




< ext4f > 


1 






<Packet data category> 


All 


OPTIONAL (NG-DECT Packet Data 
Category). 






"1 X X X X X x"B 


C692 (Channel Gp supported). 




< exte > 


0,1 
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Information element 


Field within the 
information element 


Standard values 

within the 

field/information 

element 


Normative action/comment 




< Blind slot indication > 


All 


PT shall set the value according to its 
support; FT shall understand all values 
in order to be able to setup bearers. 
Value "11" shall be used to indicate that 
the FT shall read the following SPx 
fields in order to establish the exact PT 
limitations (see note 4). 




< SPO > to < SP4 > 


All 


PT shall set the value according to its 
support; FT shall understand all values 
in order to be able to setup bearers 
(see note 4). 




< ext6a > 


1 






<SP5>to<SP11 > 




PT shall set the value according to its 
support; FT shall understand all values 
in order to be able to setup bearers 
(see note 4). 


C691 : IF DPRS-M.23 THEN MANDATORY ELSE OPTIONAL. 
C692: IF DPRS-M.19 THEN MANDATORY ELSE OPTIONAL. 


NOTE 1 : At least one of these bit maps shall contain 1 . 

NOTE 2: At least one of these bit maps shall contain 1 . 

NOTE 3: All this values are out of the scope of the DPRS and need not to be included; however, if an application 
wished to indicate Display capabilities including octets from Octet 3d onwards, these fields may be set to 
"Not applicable". 

NOTE 4: PTs that have limitations shall always indicate them. However, as this requirement for indication of the PT 
blind slots has been introduced to DPRS after version 1.1.1, some PTs developed before this change may 
still have limitation but will not be able to indicate them to the FT. Therefore, a FT supporting fast setup 
should be aware that failure of the setup may be due to PT limitations which has not been announced. 
Some examples of possible limitations could be inability of the PT to receive setup on slots adjacent to the 
slot on which the PT is locked or currently transmitting, or PT is able to receive only on every second slot 
odd or even. In such situation the FT should repeat the setup on different slot expecting possible limitations. 

NOTE 5: All Profile indicators fields shall be included and set according to the support of the particular item. For 
backwards compatibility, if Profile_indicator_5 is not included it shall be understood that the PT supports 
only 2-level modulation scheme. 



A. 1 . 1 2.2 Broadcast attributes management (modify clause 1 2. 1 6 of 
EN 301 649) 

Clause 12.16 of EN 301 649 [16] shall be modified as follows: 

12.16 Broadcast attributes management 

RFPs belonging to the same LA shall broadcast the same values of higher layer attributes (see EN 300 175-5 [5], 
annex F) at any given time. 

12.16.1 Higiner Layer (HL) capabilities 

The Higher Layer Fixed Part Information (HLFPI) field shall be used with the information described in table 98. In the 
case that the FP is capable of supporting encryption, this shall use the DECT standard algorithm and shall be signalled 
to the PP by the setting of the MAC Q channel Higher Layer Information (HLI) message bit a3-y. 

The DPRS PP shall be capable to read and interpret at least the following broadcast attributes codings during locking 
procedure. In the locked state the PP may assume them as static. 



£75/ 



81 



ETSI TS 102 527-2 VI. 1.1 (2007-06) 



Table 98: Higher Layer capabilities interpretation by the PP 



BIT Number 


Attribute 


Value 


Note 


^34 


Non-voice circuit switched 
service 


1 




^35 


Non-voice packet switched 
service 







336 


Standard authentication 
required 


[0,1] 




^37 


Standard ciphering 
supported 


[0,1] 




^38 


Location registration 
supported 


[0,1] 


See location update procedure as an exception. 


340 


Non-static FP 


[0,1] 


A FP which is mounted on a moving vehicle. 


342 


CLIVIS service available 


[0,1] 


FT may send this and PT need to understand it if FT 
supports CLMS services at NWK layer. 


344 


Access Rights requests 
supported 


[0,1] 


The FP can toggle this bit to enable or disable on air 
subscription. 


345 


External handover 
supported 


[0,1] 


FT may send this and PT need to understand it if 
DPRS-N.38 is supported. 


346 


Connection handover 
supported 


[0,1] 





1 2. 1 6.2 Extended Higher Layer capabilities 

The Extended Higher Layer Fixed Part Information (HLFPI) field shall be used with bit a^^ and a^^ indicating the 
support for DPRS frame relay and character oriented service and bits a27 - a33 indicating the supported interworking. Bit 
a^^ shall be used to indicate the support of asymmetric bearers. 

Table 99: Extended Higher Layer capabilities interpretation by the PP 



BIT Number 


Attribute 


Value 


Note 


327 


Generic Me6\a 
encapsulation transport 


[0,1] 


Depends on the actual service supported by the 
terminal (see note 1). 


329 


Ethernet 


[0,1] 


Depends on the actual service supported by the 
terminal (see note 1). 


A30 


Token Ring 


[0,1] 


Depends on the actual service supported by the 
terminal (see note 1). 


A31 


IP 


[0,1] 


Depends on the actual service supported by the 
terminal (see note 1). 


A32 


PPP 


[0,1] 


Depends on the actual service supported by the 
terminal (see note 1). 


A33 


V.24 


[0,1] 


Depends on the actual service supported by the 
terminal (see note 1). 


A4I 


Asymmetric Bearers 
Supported 


[0,1] 


Depends on the actual service supported by the 
terminal. 


A45 


DPRS Stream support 


[0,1] 


Depends on the actual service supported by the 
terminal (see note 2). 


A46 


DPRS FREL support 


[0,1] 


Depends on the actual service supported by the 
terminal (see note 2). 


NOTE 1 : At least one of these bits shall be set to "1 ". 
NOTE 2: At least one of these bits shall be set to "1 ". 
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1 2. 1 6.3 Extended Higher Layer capabilities part 2 

The Extended Higher Layer capabihties, part 2, Fixed Part Information field shall be used with bits < a25 - ^2^ > 
indicating the packet data Category of the FT. 

Table 99b: Extended Higher Layer Capabilities part 2 interpretation by the PP 



BIT Number 


Attribute 


Value 


Note 


< 325 ' ^28 > 


NG-DECT Packet Data 
Category 





No Packet data supported or non categorized 
system 






1 


Cat 1 : data Category 1 (see note) 






2 


Cat 2: data Category 2 (see note) 






3 


Cat 3: data Category 3 (see note) 










































NOTE: See clause 4.2.4 for definition of Pacl<et data Categories. Pacl<et data Categories are incremental: Cat 3 
systems also support Cat 1 and Cat 2; Cat 2 systems also support Cat 1 . 



A.2 Amendments to EN 300 175-3 (DECT CI; MAC layer) 

The following amendments to EN 300 175-3 [3] shall apply for the purpose of the present document. 

A.2.1 Symbols and abbreviations 

A.2. 1 . 1 Symbols (add to clause 3.2 of EN 300 1 75-3) 

The following entries shall be added to clause 3.2 of EN 300 175-3 [3]: 



3.2 



Symbols 



E type 
Eh-U type 

E/U-mux 

IpF 

SIpp 
U type 



B -field multiplexer mode when the slot carries signalling only (channels Cp, Gp and M) 

B-field multiplexer mode when the slot carries U-plane data (channel Ipp) AND signalling 

(channels Gp and M) 

B-field multiplexer (switching between E, U or Eh-U modes) 

higher layer Information channel (protected) transported multiplexed with signalling in the Eh-U 

type slots 

higher layer Information channel (protected) with single subfield format 

higher layer connectionless channel (protected) transported multiplexed with signalling in the E+U 

type slots 

B-field multiplexer mode when the slot carries U-plane data only (channels Ij^ or Ip) 



A.2.1 .2 Abbreviations (remove from clause 3.3 of EN 300 1 75-3) 

The following entry shall be removed from clause 3.3 of EN 300 175-3 [3]: 

3.3 Abbreviations 

E/U-MUX switch between E-type and U-type MUltipleXes 
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A.2.2 Higher layer U-Plane channels ipp and Sip 



'PF 

A.2.2. 1 The higher layer U-Plane channels (modify clause 5.3.1 .2 of 
EN 300 175-3) 

Clause 5.3.1.2 of EN 300 175-3 [3] shall be modified as follows: 

5.3.1 .2 The higher layer U-Plane channels, I 

Higher layer information from the DLC U-plane uses the I channels. These are the Ij,^ channel and the Ip channel, and 
they have different MAC layer protection schemes. The higher layers choose one of the two channels, the Ij^ and Ip 
channels shall not be used in parallel for the same connection. 

The If^ information is protected by limited MAC layer error detection (X -field) and may include a minimum delay mode 
for coded speech transmission. Depending on the physical packet size the MAC layer processes l^ channel data in 
fields of different length. 

The Ip information is protected by MAC layer procedures, either error correction based on a modulo 2 retransmission 
scheme or just error detection based on 16 bits or 32 bits CRCs or error correction with Turbo Code. Three B-field 
formats for Ip channel data are available: 

• the Encoded protected format; 

• the Multisubfield protected format (service Ip); and 

• the Singlesubfield protected format (service Ipo). 

The DLC layer requests a service type, maximum allowed transmission time, and target and minimum acceptable 
numbers of uplink and downlink bearers which the MAC layer tries to provide. 

The Ipp channel (see clause 5.3.1.4) can also be used for transporting U-plane information, in slots carrying at the same 
time channels Gp and M. 

A.2.2. 2 The higher layer U-Plane channel in E-i-U type slots, Ipp (add to 
clause 5.3.1 of EN 300 1 75-3) 

A new clause with the following text shall be added to clause 5.3.1 of EN 300 175-3 [3]: 

5.3.1 .4 The higher layer U-Plane channel in E-i-U type slots, Ipp 

The channel Ipp is used to carry U-plane information in slots where the B-field multiplexer is in Eh-U type mode (see 
clause 6.2.2): In Eh-U type, the B-field carries C-plane signalling (channels Gp and M) in some of the subfields and U- 
plane data in the other subfields. The number of subfields used for U-plane data and C-plane signalling varies 
depending on modulation, slot type, and amount of signalling to be transported. The possible combinations are defined 
in clause 6.2.2.3.1. 

At least one subfield carrying C-plane signalling should exist. Subfields with U-plane data are always at the end of the 
slot. 

Ipp channel could be used either if the regular I service is Ip or Ipg , and either if the service is provided with error 
correction (Ip_error_correct) or error detection only (Ip_error_detect). 

Due to the variable number of subfields allocated for U-plane data, and the different size of the U-plane bits per slot, 
compared to normal Ip or IpQ size, a segmentation mechanism is required to split regular Ip or IpQ packets for 
transporting by the Ipp channel. This mechanism uses the MAC message "Null or segmentation information" 
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(see clause 7.3.3) and the NCF header of Gp channel message (see clause 7.3.6) in order to exchange segmentation 
information. 

Ipp channel operation is described in clause 10.8.4. 

Ipp channel is protected by MAC layer CRC (16 bits CRC for each subfield) and can be used with and without MAC 
ARQ. 

A.2.2.3 The connectionless U-Plane channel in Eh-U type slots, Slpp (add to 
clause 5.3.2 of EN 300 175-3) 

A new clause with the following text shall be added to clause 5.3.2 of EN 300 175-3 [3]: 

5.3.2.3 The connectionless U-Plane channel in E+U type slots, SIpp 

The equivalent of the Ipp channel for connectionless message control is the channel SIpp. The SIpp channel allows the 
transmission of reduced rate connectionless U-plane data multiplexed with connectionless MAC signalling broadcast. 

SIpp inherits all capabilities and procedures of Ipp, however with the following limitations: 

• SIpp can only operate in error_detection mode. 

• There is no Gp channel in connectionless bearers. 

A system can only support SIpp channel if it also supports channel Sip and channel Ipp. 

A.2.3 Symmetric and Asymmetric connections 

A.2.3.1 Symmetric connections (modify clause 5.6.2.1 of EN 300 1 75-3) 

Text of clause 5.6.2.1 of EN 300 175-3 [3] and table 5.1 in the same clause shall be modified as follows: 

5.6.2.1 Symmetric connections 

A DECT symmetric connection has the same number of bearers in both directions and is composed of duplex bearers 
only. 

The five symmetric service types are distinguished by their I channel data protection and their throughput: 
type 1 : If^_minimum_delay: limited error protection, minimum delay, fixed throughput; 

type 2: If^_normal_delay: limited error protection, normal delay, fixed throughput; 

type 3: Ip_error_detection: error detection capability, fixed throughput; 

type 4: Ip_error_correction: error correction, variable throughput; and 

type 5: Ip_encoded_protected. 

NOTE 1 : Service type 1 (Ij,^_minimum _delay) exists only as single bearer service. Ijvj_minimum_delay and 
If^_normal_delay services have different I channel flow control (see clause 8.4). 

NOTE 2: The throughput of service types 2 and 3 can vary if the MAC layer changes the number of bearers 
assigned to that connection. 

Service type 3 using the single subfield protected B-field format is called IpQ_error_detection; service types 4 using the 
single subfield protected B-field format is called IpQ_error_correction. 
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The bearers of a symmetric connection shall be normally in U-type multiplexer mode. However, from time to time, they 
can be switched to E or E+U type mode to exchange signalling messages (channels M, Gp or Cp). During the time the 
bearer is in E or E+U type mode it cannot carry Ij^, Ip, IpQ channel data. However, if they are in E+U type mode, they 
can carry Ipp channel data; 

The most important parameters of the five symmetric services are listed in tables 5.1, 5.2 and 5.3. 

NOTE 3: In the channel capacity calculations, it is assumed that the all bearers are in U-type mux mode, since the 
switch to E-type or E+U-type, if needed, only happens occasionally. 
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Table 5.1 : Symmetric services (2-level modulation) 



ST 


1 channel 
capacity (kbit/s) 


B-field 
multiplex 
schemes 


NP 


err 
det 


err 
corr 


maximum 
Cp (kbit/s) 


delay 
(ms) 


1d2 

1 12 {j=640) 

1f2 

1h2 


80 

64 

32 

8-I-J/10 


(U80a,E80) 
(U64a,E64) 
(U32a,E32) 
(U08a,E08) 


'n 
'n 
'n 
'n 


No 
No 
No 
No 


No 
No 
No 
No 


64,0 
51,2 
25,6 
6,4 


-10 
-10 
-10 
-10 


2d2 
212 {j=640) 
212 {j=672) 

2f2 

2h2 


kx80 
kx64 

k X 67,2 
kx32 

8-I-J/10 


(U80a,E80) 
(U64a,E64) 
(U67a,E67) 
(U32a,E32) 
(U08a,E08) 


'n 
'n 
'n 
'n 
'n 


No 
No 
No 
No 
No 


No 
No 
No 
No 
No 


64,0 
51,2 
51,2 
25,6 
6,4 


15 
15 
15 
15 
15 


3d2 
312 (j=640) 
312 (j=672) 

3f2 

3h2 


kx64,0 
kx51,2 
kx51,2 
kx25,6 
6,4 


(U80b,E80) 
(U64b,E64) 
(U67b,E67) 
(U32b,E32) 
(U08b,E08) 


'p 
'p 

p 
'p 
'p 


Yes 
Yes 
Yes 
Yes 
Yes 


No 
No 
No 
No 
No 


64,0 
51,2 
51,2 
25,6 
6,4 


15 
15 
15 
15 
15 


4d2 
412 {j=640) 
412 {j=672) 

4f2 

4h2 


<kx64,0 
<kx51,2 
<kx51,2 
<kx25,6 
<6,4 


(U80b,E80) 
(U64b,E64) 
(U67b,E67) 
(U32b,E32) 
(U08b,E08) 


'p 
'p 

p 
'p 
'p 


Yes 
Yes 
Yes 
Yes 
Yes 


Yes, ARQ 
Yes, ARQ 
Yes, ARQ 
Yes, ARQ 
Yes, ARQ 


64,0 
51,2 
51,2 
25,6 
6,4 


var 
var 
var 
var 
var 


3d2ssub 
3l2ssub {j=640) 
3l2ssub {j=672) 

3f2ssub 


kx76,8 
kx60,8 
kx64,0 
k X 30,4 


U80c 
U64c 
U67c 
U32c 


'PQ 
'PQ 
'pQ 
'pQ 


Yes 
Yes 
Yes 
Yes 


No 
No 
No 
No 


64,0 
51,2 
51,2 
25,6 


15 
15 
15 
15 


4d2ssub 
4l2ssub {j=640) 
4l2ssub {j=672) 

4f2ssub 


<kx76,8 
kx60,8 
kx64,0 

<kx30,4 


U80c 
U64c 
U67c 
U32c 


'pQ 
'pQ 
'pQ 
'pQ 


Yes 
Yes 
Yes 
Yes 


Yes, ARQ 
Yes, ARQ 
Yes, ARQ 
Yes, ARQ 


64,0 
51,2 
51,2 
25,6 


var 
var 
var 
var 


5d2encoded 

5l2encoded (j=640) 

5f2encoded 

5h2encoded 


kx 
(60,0/64,0/80,0) 

k X 
(48,0/51,2/64,0) 

k X 
(24,0/25,6/32,0) 
k X (6,0/6,4/8,0) 


(U80d, E80) 
(U64d, E64) 
(U32d, E32) 
(U08d, E08) 


Ip 
Ip 
Ip 
Ip 


Yes 
Yes 
Yes 
Yes 


Yes, code 
Yes, code 
Yes, code 
Yes, code 


64,0 
51,2 
25,6 
6,4 


15 
15 
15 
15 


ST: Service Type: 

xdy = type x double slot, modulation y levels; 

xly = type x long slot {j=640 or j=672), modulation y levels; 

xfy = type x full slot, modulation y levels; 

xhy = type x half slot, modulation y levels; 

ssub = single subfield protected B-field format, 
encoded: Encoded protected B-field format; The 1 channel capacity varies in function of the adaptive code rate r. 
NP: Name of the U-plane channel (1^^, Ip, or Ipg); 

err. det.: error detection capability. 

err. corr.: error correction capability (ARQ or channel coding); 

max. Cp: maximum Cp channel throughput. 

dly: approximate delay incurred by 1 channel data in ms. "var" is variable. 

t: the target number of duplex bearers; w < t. 

k: the actual number of duplex bearers; w < k < t. 


NOTE: Refer to clause 6.2.2.2 for details of B-field multiplex schemes. 
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A.2.3.2 Asymmetric connections (modify clause 5.6.2.2 of EN 300 1 75-3) 

Text of clause 5.6.2.2 of EN 300 175-3 [3] and table 5.4 in the same clause shall be modified as follows: 

5.6.2.2 Asymmetric connections 

A DECT connection is called asymmetric if it includes double simplex bearers and, as consequence of it, has different 
number of bearers in both directions. 

NOTE 1: Simplex bearers are always allocated in pairs. A pair of simplex bearers in opposite directions is called 

"duplex bearer". A pair of simplex bearers in the same direction is called "double simplex bearer". In both 
cases, pairs of simplex bearers are one half TDMA frame apart. 

General principles: 

a) an asymmetric connection is composed of d duplex bearers plus s double simplex bearers, with both d> I, s 

>i; 

b) all double- simplex bearers shall go in the same direction. The direction of the double-simplex bearers is, by 
definition, called the "forward direction" of the connection. The opposite one is the "backward direction" or 
"reverse direction"; 

c) there exists k simplex bearers in the forward direction , being k = d + 2*s; 

d) there exist m + n simplex bearers in the backward direction being m + n = d; 
NOTE 2: A: > m -H n > 1 in all cases. 

e) the n simplex bearers in the reverse direction are called "special" bearers. These bearers shall be in E-type or 
E-nU-type multiplexer mode (see clause 6.2.2.2) and shall carry the "bearer quality in an asymmetric 
connection" message (see clause 7.3.4.4) in subfield BO. They are used to report reception quality on the 
double simplex bearers in the forward data direction and to carry Gp channel data. These special bearers shall 
not carry Ij^, Ip or Ipg channel data. However, if the mode is Eh-U type, they can carry Ipp channel data, and if 
the mode is E-type, they can carry Cp channel signalling; 

NOTE 3: A special bearer is, by definition, a reverse bearer carrying the "bearer quality report in an asymmetric 
connection" message. 

f) the number of special bearers shall be n > 1 . However, some profiles could allow, by negotiation, to drop the 
number of n bearers to n = in some cases. In such situation the n bearer becomes an m bearer. In all cases 
(n + m) > I; 

NOTE 4: It should be assumed that the most usual case will be n = 1 (one special bearer). 

NOTE 5: The suppression of the "bearer quality in an asymmetric connection" (n = 0) deactivates the DECT basic 
quality feedback mechanism (bits Q1/Q2), and should only be used under very good and steady radio 
quality conditions (i.e.: very short range links). In case of incidental air interface errors, the message 
"bearer and connection control" could be used by the receiver side to request handover or antenna switch. 
However, this mechanism has a slower response time and a limited control capability and will not handle 
properly the case of simultaneous loss of quality on several bearers. 

g) the m simplex bearers in the reverse direction shall be normally in U-type multiplexer mode and will carry Ip^, 
Ip or Ipg channel data. However, it is allowed to switch occasionally them to E or Eh-U type mode to exchange 
signalling messages (channels M, Gp or Cp) if the capacity of the n bearers is not enough for it. During the 
time the bearers are in E or Eh-U type mode they cannot carry Ij^, Ip, IpQ. If the mode is E+U type, they can 
carry Ipp channel data; 
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NOTE 6: The number of m bearers can be zero, however n + m>\. 

h) all the k simplex bearers in the forward direction shall be normally in U-type multiplexer mode. However, 
from time to time, some of them can be switched to E or E+U type mode to exchange signalling messages 
(channels M, Gp or Cp). During the time the bearers are in E or E+U type mode they cannot carry Ij^, Ip, IpQ 

channel data. However, if the mode is E+U type, they can carry Ipp channel data. 

NOTE 7: Only the bearers that are part of a duplex bearer can be switched to E-type or E+U-type mode. 

NOTE 8: It is not recommended to switch forward bearers to E or E+U type mux, only to carry Gp channel. Instead 
of it, the alternative mechanisms provided by some LU services (i.e. LUlO) may be used. 

The four asymmetric service types are distinguished by their I channel data protection and their throughput: 
type 6: If^_normal_delay: limited error protection, normal delay, fixed throughput; 

type 7: Ip_error_detection: error detection capability, fixed throughput; 

type 8: Ip_error_correction: error correction, variable throughput; 

type 9: Ip_encoded_protected. 

Service type 6 using the single subfield protected B-field format is called Ipg_error_detection; service types 7 using the 
single subfield protected B-field format is called IpQ_error_correction. 

Tables 5.4 to 5.6 show the most important parameters for asymmetric connections. The first line in each description 
defines the forward data direction. The second and third line describe the reverse direction. 

NOTE 9: In the channel capacity calculations, it is assumed that the all bearers of the forward channel are in U-type 
mux mode, since the switch to E-type or E+U-type only happens occasionally. 

Table 5.4: Asymmetric services (2-level modulation) 



ST 


1 channel capacity (kbit/s) 

Forward channel 
Backward channel m bearers 
Backward channel n bearers 


B-field multiplex 
schemes 


NP 


Err det. 


Err corr. 


max. Cp 
(kbit/s) 


6d2 


kx80 

m x80 

variable: to (n x 6,4 x 9) 


(U80a,E80) 

(U80a,E80) 

(E80) 


'n 
'n 

IpF 


No 
No 
Yes 


No 
No 
No 


d X 64,0 
m X 64,0 
n X 57,6 
(note 1) 


612 (j=640) 


kx64 

m x64 

variable: to (n x 6,4 x 7) 


(U64a,E64) 

(U64a,E64) 

(E64) 


'n 
'n 

IpF 


No 
No 
Yes 


No 
No 
No 


dx51,2 
mx51,2 
n X 44,8 
(note 1) 


612 (j=672) 


kx67,2 

m X 67,2 

variable: to (n x 6,4 x 7) 


(U67a, E67) 

(U67a, E67) 

(E67) 


'n 
'n 

IpF 


No 
No 
Yes 


No 
No 
No 


dx51,2 
mx51,2 
n X 44,8 
(note 1) 


6f2 


kx32 

m x32 

variable: to (n x 6,4 x 3) 


(U32a,E32) 

(U32a,E32) 

(E32) 


'n 
'n 

IpF 


No 
No 
Yes 


No 
No 
No 


dx25,6 
m X 25,6 
nx19,2 
(note 1) 


7d2 


kx64 

m x64 

variable: to (n x 6,4 x 9) 


(U80b,E80) 

(U80b,E80) 

(E80) 


'p 
'p 
IpF 


Yes 
Yes 
Yes 


No 
No 
No 


d X 64,0 
m X 64,0 
n X 57,6 
(note 1) 


712 (j=640) 


kx51,2 

mx51,2 

variable: to (n x 6,4 x 7) 


(U64b,E64) 

(U64b,E64) 

(E64) 


'p 
'p 
IpF 


Yes 
Yes 
Yes 


No 
No 
No 


dx51,2 
mx51,2 
n X 44,8 
(note 1) 


712 (j=672) 


kx51,2 

mx51,2 

variable: to (n x 6,4 x 7) 


(U67b,E67) 

(U67b,E67) 

(E67) 


'p 
'p 
IpF 


Yes 
Yes 
Yes 


No 
No 
No 


dx51,2 
mx51,2 
n X 44,8 
(note 1) 
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ST 


1 channel capacity (kbit/s) 

Forward channel 
Backward channel m bearers 
Backward channel n bearers 


B-field multiplex 
schemes 


NP 


Err det. 


Err corr. 


max. Cp 
(kbit/s) 


7f2 


kx25,6 

m X 25,6 

variable: to (n x 6,4 x 3) 


(U32b,E32) 

(U32b,E32) 

(E32) 


Ip 
Ip 

IpF 


Yes 
Yes 
Yes 


No 
No 
No 


dx25,6 
m X 25,6 
nx19,2 
(note 1) 


7d2ssub 


kx76,8 

m X 76,8 

variable: to (n x 6,4 x 9) 


(U80c) 
(U80c) 
(E80) 


'PQ 
'PQ 
IpF 


Yes 
Yes 
Yes 


No 
No 
No 


d X 64,0 
m X 64,0 
n X 57,6 
(note 1) 


7l2ssub (j=640) 


kx60,8 

m X 60,8 

variable: to (n x 6,4 x 7) 


(U64c) 
(U64c) 
(E64) 


'pQ 
'pQ 
IpF 


Yes 
Yes 
Yes 


No 
No 
No 


dx51,2 
mx51,2 
n X 44,8 
(note 1) 


7l2ssub (j=672) 


kx64 

m x64 

variable: to (n x 6,4 x 7) 


(U67c) 
(U67c) 
(E67) 


'pQ 
'pQ 
IpF 


Yes 
Yes 
Yes 


No 
No 
No 


dx51,2 
mx51,2 
n X 44,8 
(note 1) 


7f2ssub 


kx30,4 

m X 30,4 

variable: to (n x 6,4 x 3) 


(U32c) 
(U32c) 
(E32) 


'pQ 
'pQ 
IpF 


Yes 
Yes 
Yes 


No 
No 
No 


dx25,6 
m X 25,6 
nx19,2 
(note 1) 


8d2 


<kx64 

<mx64 

variable: to (n x 6,4 x 9) 


(U80b,E80) 

(U80b,E80) 

(E80) 


'p 
'p 
IpF 


Yes 
Yes 
Yes 


Yes, ARQ 
Yes, ARQ 

Yes, 
ARQNo 


d X 64,0 
m X 64,0 
n X 57,6 
(note 1) 


812 {j=640) 


<kx51,2 

<mx51,2 

variable: to (n x 6,4 x 7) 


(U64b,E64) 

(U64b,E64) 

(E64) 


'p 
'p 
IpF 


Yes 
Yes 
Yes 


Yes, ARQ 

Yes, ARQ 

Yes, ARQ 

No 


dx51,2 
mx51,2 
n X 44,8 
(note 1) 


812 {j=672) 


<kx51,2 

<mx51,2 

variable: to (n x 6,4 x 7) 


(U67b,E67) 

(U67b,E67) 

(E67) 


'p 
'p 
IpF 


Yes 
Yes 
Yes 


Yes, ARQ 

Yes, ARQ 

Yes, ARQ 

No 


dx51,2 
mx51,2 
n X 44,8 
(note 1) 


8f2 


<kx25,6 

<mx25,6 

variable: to (n x 6,4 x 3)n x 




(U32b,E32) 

(U32b,E32) 

(E32) 


'p 

'p 

IpF- 


Yes 
Yes 
Yes 


Yes, ARQ 

Yes, ARQ 

Yes, ARQ 

No 


dx25,6 
m X 25,6 
nx19,2 
(note 1) 


8d2ssub 


<kx76,8 

< m X 76,8 

variable: to (n x 6,4 x 9) 


(U80c) 
(U80c) 
(E80) 


'pQ 
'pQ 
IpF 


Yes 
Yes 
Yes 


Yes, ARQ 

Yes, ARQ 

Yes, ARQ 

No 


dx64 
m x64 
n X 57,6 
(note 1) 


8l2ssub (j=640) 


kx60,8 

m X 60,8 

variable: to (n x 6,4 x 7) 


(U64c) 
(U64c) 
(E64) 


'pQ 
'pQ 
IpF 


Yes 
Yes 
Yes 


Yes, ARQ 

Yes, ARQ 

Yes, ARQ 

No 


dx51,2 
mx51,2 
n X 44,8 
(note 1) 


8l2ssub (j=672 


kx64 

m x64 

variable: to (n x 6,4 x 7) 


(U67c) 
(U67c) 
(E67) 


'pQ 
'pQ 
IpF 


Yes 
Yes 
Yes 


Yes, ARQ 

Yes, ARQ 

Yes, ARQ 

No 


dx51,2 
mx51,2 
n X 44,8 
(note 1) 


8f2ssub 


<kx30,4 

<mx30,4 

variable: to (n x 6,4 x 3) 


(U32c) 
(U32c) 
(E32) 


'pQ 
'pQ 
IpF 


Yes 
Yes 
Yes 


Yes, ARQ 

Yes, ARQ 

Yes, ARQ 

No 


dx51,2 
mx51,2 
nx19,2 
(note 1) 


9d2encoded 


< k X (60,0/64,0/80,0) 

< m X (60,0/64,0/80,0) 
variable: to (n x 6,4 x 9) 


(U80d,E80) 

(U80d,E80) 

(E80) 


Ip 
Ip 
IpF 


Yes 
Yes 
Yes 


Yes, code 

Yes, code 

No 


dx64 
m x64 
n X 57,6 
(note 1) 


9l2encoded 
(j=640) 


<kx (48,0/51,2/64,0) 

<mx(48,0/51, 2/64,0) 

variable: to (n x 6,4 x 7) 


(U64d,E64) 

(U64d,E64) 

(E64) 


Ip 
Ip 
IpF 


Yes 
Yes 
Yes 


Yes, code 

Yes, code 

No 


dx51,2 
mx51,2 
n X 44,8 
(note1) 
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ST 


1 channel capacity (kbit/s) 

Forward channel 
Backward channel m bearers 
Backward channel n bearers 


B-field multiplex 
schemes 


NP 


Err det. 


Err corr. 


max. Cp 
(kbit/s) 


9f2encoded 


< k X (24,0/25,6/32,0) 

< m X (24,0/25,6/32,0) 
variable: to (n x 6,4 x 3) 


(U32d,E32) 

(U32d,E32) 

(E32) 


Ip 
Ip 

IpF 


Yes 
Yes 
Yes 


Yes, code 

Yes, code 

No 


dx25,6 
m X 25,6 
nx19,2 
(note1) 


ST: Service Type: 

xdy = type x double slot, y levels modulation; 

xly = type x long slot (j=640 or j=672), y levels modulation; 

xfy = type x full slot, y levels modulation; 

xh = type X half slot, where x = the Service Type; 

ssub = singlesubfield protected B-field format, 
encoded: Encoded protected B-field format; The 1 channel capacity varies in function of the adaptive code rate r; 
NP: Name of the U-plane channel (1,^, Ip, or Ipp); 

err.det.: error detection capability. 

err.corr.: error correction capability and type (ARQ or channel coding); 

max.Cp: maximum Cp channel throughput. 

k: the actual number of simplex bearers in the forward direction. 

m: the actual number of simplex data bearers in the reverse direction with U-type mux. 

n: the actual number of simplex special bearers in the reverse direction. 


NOTE 1 : The Cp capacity in n type bearers includes the reduction due to the "bearer quality in an asymmetric 

connection" sent on this bearer. 
NOTE 2: Refer to clause 6.2.2.2 for details of B-field multiplex schemes. 



A.2.4 B-field control multiplexer 

A.2.4.1 B-field control multiplexer (E/U-IVlUX) (modify clause 6.2.2.2 of 
EN 300 175-3) 

Text of clause 6.2.2.2 of EN 300 175-3 [3] and table 6.20 in the same clause shall be modified as follows: 

6.2.2.2 B-field control multiplexer (E/U-MUX) 

The E/U-MUX switches the B-field between three types of multiplex, the E-type, the U-type and the Eh-U type. 

1) E-type: 

For traffic bearers the B-field is used to carry M channel data and/or Cp channel data and/or Gp channel 
data. For connectionless bearers the B-field is used to carry M channel data and/or CLp channel data. 

2) U-type: 

The B-field is used to carry either Ij^ channel data or Ip channel data, or SIj,^ or Sip channel data. 

E-HU-type: 



3) 



The B-field is used to carry M channel data and/or Gp channel data and protected U plane data. The 
U-plane channel transported by this format is named Ipp channel. For connectionless bearers the B-field 
carries M channel data and SIpp channel data. 

NOTE: The Ipp channel incorporates a segmentation mechanism in order to transport Ip or IpQ size packets by the 
variable capacity Ipp channel (see clause 10.8.4 for description of the Ipp channel operation). 

The E/U MUX operates on a slot-by-slot basis in response to immediate traffic demands. The chosen multiplex for each 
frame is indicated with the BA bits in the A-field header. E-type or Eh-U type multiplexers have priority over U-type 
multiplex. 
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The B-field multiplexers are defined in tables 6.20 to 6.22a. 



Table 6.20: B-field multiplexes (2-level) 



B-field multiplex for 2-level modulation 


E/U 


B-field format 


Logical 
channel 


D80- 
field 


D64- 
field 


D67- 
field 


D32- 
field 


DOS- 
field 


E80 


E64 


E67 


E32 


(note 2) 


E+U 


IVIultisubfield protected 


M or GpOr 
IpForSlpF 


E80 
U80a 
U80b 
U80c 
U80d 


E64 
U64a 
U64b 
U64c 
U64d 


E67 


E32 


E08 
U08a 
U08b 

U08d 


E 
U 
U 

u 
u 


IVIultisubfield protected 

Unprotected 

Multisubfield protected 

Singlesubfield protected 

Encoded protected 
(see note 1 ) 


M orGpOr Cp 
InO^SIn 
Ip or Sip 

Ip 
Ip 


U67a 


U32a 


U67b 


U32b 


U67c 


U32c 


- 


U32d 


NOTE 1 : The Encoded protected format is defined in annex 1. 
NOTE 2: E+U mode is not possible in slot type D08. 



The E-type and E+U type multiplexers always use the multisubfield protected B-field format. The possible modes of the 
E-type and E+U type multiplexers are defined in clause 6.2.2.3. 

The U-type multiplex in connection oriented services may use either: the single-subfield protected B-field format, the 
multi-subfield protected B-field format, or the unprotected B-field format. This choice is defined at connection 
establishment for all bearers belonging to that connection, and it corresponds to the logical channel required for the 
chosen service, IpQ ,Ip or l^. The chosen format is maintained until it is re-negotiated or the connection ends. 

A.2.4.2 B-field control multiplexer in E-type and E+U-type modes (modify 
clause 6.2.2.3 of EN 300 175-3) 

A.2.4.2. 1 B-field control multiplexer in E-type and E-i-U-type modes (modify 
clause 6.2.2.3 of EN 300 175-3) 

Title of clause 6.2.2.3 of EN 300 175-3 [3] shall be modified as follows: 

6.2.2.3 B-field multiplexer in E-type and E-i-U-type modes 

A.2.4.2. 2 E-type and E-i-U-type modes for slots with more than one subfield (modify 
clause 6.2.2.3.1 of EN 300 175-3) 

Title, title of clauses and text of clause 6.2.2.3.1 of EN 300 175-3 [3] and tables 6.23, 6.26 and 6.33 in the same clause 
shall be modified as follows: 

6.2.2.3.1 E-type and EH-U-type modes for slots with more than one subfield 

This clause applies to all cases except half slot with 2-level modulation. 

6.2.2.3.1 .1 Slot modes with more than one subfield: E-type mux mode 

For double slot, long slot (j=640 or j=672), full slot and half slot modes, in case of 2-level, 4-level, 8-level, 16-level and 
64-level modulation all B-subfields are used for control. The following types of information have to be multiplexed: 

• higher layer control from the Cp or CLp logical channel; 

• MAC layer connection related signalling; 

• higher layer information from the Gp logical channel; and 
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• MAC layer control to describe the contents of the subfields. 

All extended MAC control and Gp segments carried in the B-subfields have a header with a bit indicating if the next 
subfield in the same databurst contains an extended MAC control or Gp segment, or whether it contains higher layer 
control channels Cp or CLp). 

6.2.2.3.1 .2 Slot modes with more than one subfield: E+U type mux mode 

For double slot, long slot (j=640 or j=672), full slot and half slot modes, in case of 2=level and 4-level modulation, the 
B-subfields are used for control or for transporting Ipp channel U-plane data. 

The following types of information have to be multiplexed: 

• MAC layer connection related signalling. 

• Higher layer information from the Gp logical channel. 

• MAC layer control to describe the contents of the subfields. 

• U-plane data (channels Ipp and SIpp). 

• MAC layer control to describe the segmentation of channels Ipp and SIpp 
The following rules shall be fulfilled: 

• At least the first subfield shall carry signalling. 

• Subfields transporting signalling shall precede subfields carrying Ipp channel data. 

• The number of subfields carrying Ipp channel data is variable from 1 to N-1 subfields, being N the number of 
subfields. 

• No Cp channel signalling can be transported by E+U type mux slots. 

• If there are not enough signalling messages plus Ipp channel segments to fill the slot, the slot shall be filled 
with the MAC message "NULL" (clause 7.3.3) repeated as many times as needed and placed after the valid 
signalling subfields and before the Ipp channel segments. 

• All extended MAC control and Gp segments carried in the B-subfields have a header with a bit indicating if 
the next subfield in the same databurst contains an extended MAC control or Gp segment, or whether it 
contains U-plane data (channels Ipp and SIpp). 
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6.2.2.3.1.3 Double slot modes 

For D80 double slot operation (2-level modulation) the modes are given in table 6.23. 

Table 6.23: D80 double slot 2-level modes 



X 

E 
a> 

Q. 

>, 

HI 
X 

E 
a> 

Q. 

>, 

+ 
LJJ 




Subfield 




BO 


B1 


82 


B3 


B4 


B5 


B6 


B7 


B8 


B9 


* 


ModeO 


C/0 


Cf 


Cf 


Cf 


Cf 


Cf 


Cf 


Cf 


Cf 


Cf 


Cf 


C/L 


CLp 


CLp 


CLp 


CLp 


CLp 


CLp 


CLp 


CLp 


CLp 


CLp 


o 

o 
o 
o 

U) 
0) 
T3 
O 
O 

< 


Mode 1 


C/0 


M/M+Gp 


Cf 


Cf 


Cf 


Cf 


Cf 


Cf 


Cf 


Cf 


Cf 


C/L 


M 


CLp 


CLp 


CLp 


CLp 


CLp 


CLp 


CLp 


CLp 


CLp 


Mode 2 


C/0 


M/M+Gp 


M/M+Gp 


Cf 


Cf 


Cf 


Cf 


Cf 


Cf 


Cf 


Cf 


C/L 


M 


M 


CLp 


CLp 


CLp 


CLp 


CLp 


CLp 


CLp 


CLp 


Modes 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


Cf 


Cf 


Cf 


Cf 


Cf 


Cf 


Cf 


C/L 


M 


M 


M 


CLp 


CLp 


CLp 


CLp 


CLp 


CLp 


CLp 


Mode 4 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


Cf 


Cf 


Cf 


Cf 


Cf 


Cf 


C/L 


M 


M 


M 


M 


CLp 


CLp 


CLp 


CLp 


CLp 


CLp 


Modes 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


Cf 


Cf 


Cf 


Cf 


Cf 


C/L 


M 


M 


M 


M 


M 


CLp 


CLp 


CLp 


CLp 


CLp 


Mode 6 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


Cf 


Cf 


Cf 


Cf 


C/L 


M 


M 


M 


M 


M 


M 


CLp 


CLp 


CLp 


CLp 


Mode 7 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


Cf 


Cf 


Cf 


C/L 


M 


M 


M 


M 


M 


M 


M 


CLp 


CLp 


CLp 


Modes 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


Cf 


Cf 


C/L 


M 


M 


M 


M 


M 


M 


M 


M 


CLp 


CLp 


Mode 9 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


Cf 


C/L 


M 


M 


M 


M 


M 


M 


M 


M 


M 


CLp 


O 
O 

U) 
Q) 
T3 
O 
O 

< 
CQ 


Mode 10 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


C/L 


M 


M 


M 


M 


M 


M 


M 


M 


M 


M 


Mode 1 1 


C/0 


M/M+Gp 


IpF 


IpF 


IpF 


IpF 


IpF 


IpF 


IpF 


IpF 


IpF 


C/L 


M 


SIpp 


SIpp 


SIpp 


SIpp 


SIpp 


SIpp 


SIpp 


SIpp 


SIpp 


Mode 12 


C/0 


M/M+Gp 


M/M+Gp 


IpF 


IpF 


IpF 


IpF 


IpF 


IpF 


IpF 


IpF 


C/L 


M 


M 


SIpp 


SIpp 


SIpp 


SIpp 


SIpp 


SIpp 


SIpp 


SIpp 


Mode 14 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


IpF 


IpF 


IpF 


IpF 


IpF 


IpF 


IpF 


C/L 


M 


M 


M 


SIpp 


SIpp 


SIpp 


SIpp 


SIpp 


SIpp 


SIpp 


Models 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


IpF 


IpF 


IpF 


IpF 


IpF 


IpF 


C/L 


M 


M 


M 


M 


SIpp 


SIpp 


SIpp 


SIpp 


SIpp 


SIpp 


Mode 16 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


IpF 


IpF 


IpF 


IpF 


IpF 


C/L 


M 


M 


M 


M 


M 


SIpp 


SIpp 


SIpp 


SIpp 


SIpp 


Mode 16 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


IpF 


IpF 


IpF 


IpF 


C/L 


M 


M 


M 


M 


M 


M 


SIpp 


SIpp 


SIpp 


SIpp 


Mode 17 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


IpF 


IpF 


IpF 


C/L 


M 


M 


M 


M 


M 


M 


M 


SIpp 


SIpp 


SIpp 


Models 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


IpF 


IpF 


C/L 


M 


M 


M 


M 


M 


M 


M 


M 


SIpp 


SIpp 


Mode 19 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


IpF 


C/L 


M 


M 


M 


M 


M 


M 


M 


M 


M 


SIpp 


*1 = E-type mux, Cp only: BA codes 010 or 01 1 



For D80 double slot operation the A-field header coding (BA bits) shall distinguish between the following modes: 

• E-type, Cp only: mode (BA bits codes "010" and "Oil"); 

• E-type, M + Gp+Cp modes 1 to 9 (BA bits codes "100" and "101"); 
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• E type, M + Gp : mode 10: (BA bit code "110"); 

• E+Utype,M + Gp+Ipp: modes 11 to 19: (BA bit codes "110" and "111"); 

B A bit code "111" shall only be used if regular (U-type) MAC service is IP-error-correct. 

6.2.2.3.1.4 Full slot modes 

For D32 full slot operation (2-level modulation) the modes given in table 6.26 are allowed. 

Table 6.26: D32 full slot 2-level modes 



ETSI TS 102 527-2 V1.1.1 (2007-06) 



X 

E 

0) 
Q. 

LU 




Subfield 




BO 


B1 


82 


B3 


* 


ModeO 


C/0 


Cp 


Cp 


Cp 


Cp 


C/L 


CLp 


CLp 


CLp 


CLp 


o 

o 
o 
o 

w 
tu 

T3 
O 
O 

< 
DO 


Mode 1 


C/0 


M/M+Gp 


Cp 


Cp 


Cp 


C/L 


M 


CLp 


CLp 


CLp 


Mode 2 


C/0 


M/M+Gp 


M/M+Gp 


Cp 


Cp 


C/L 


M 


M 


CLp 


CLp 


Modes 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


Cp 


C/L 


M 


M 


M 


CLp 


O 
O 

tn 

CD 
T3 
O 
O 

< 

m 


Mode 4 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


C/L 


M 


M 


M 


M 


X 

E 

0) 
Q. 

+ 
LU 


Mode 5 


C/0 


M/M+Gp 


Ipp 


Ipp 


Ipp 


C/L 


M 


SIpp 


SIpp 


SIpp 


ModeO 


C/0 


M/M+Gp 


M/M+Gp 


Ipp 


Ipp 


C/L 


M 


M 


SIpp 


SIpp 


Mode 7 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


Ipp 


C/L 


M 


M 


M 


SIpp 


*1 = E-type mux, Cp only: BA codes 01 or 01 1 



For full slot D32 operation the A-field header coding (BA bits) will distinguish between the following modes: 

• E-type, Cp only: mode (BA bits codes "010" and "01 1"); 

• E-type, M + Gp+Cp modes 1 to 3 (BA bits codes "100" and "101"); 

• E type, M + Gp : mode 4: (BA bit code "110"); 

• E+Utype, M + Gp+Ipp: modes4to7: (BA bit codes "110" and "111"). 

B A bit code "111" shall only be used if regular (U-type) MAC service is IP-error-correct. 
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6.2.2.3.1.6 Long slot (j=640 or j=672) modes 

For D64/D67 long slot operation with j=640/672 (2-level modulation) the modes are given in table 6.33. 

Table 6.33: D64/D67 long slot (j=640/672) 2-level modes 







Subfield 




BO 


B1 


82 


B3 


B4 


85 


86 


87 


X 

E 
tt> 
a. 
2r 

LU 
X 

E 

CD 

a. 
>, 

+ 
LU 


* 


ModeO 


C/0 


Cf 


Cf 


Cf 


Cf 


Cf 


Cf 


Cf 


Cf 


C/L 


CLp 


CLp 


CLp 


CLp 


CLp 


CLp 


CLp 


CLp 


o 

o 
o 
o 

U) 
0) 
T3 
O 
O 

< 


Mode 1 


C/0 


M/M+Gp 


Cf 


Cf 


Cf 


Cf 


Cf 


Cf 


Cf 


C/L 


M 


CLp 


CLp 


CLp 


CLp 


CLp 


CLp 


CLp 


Mode 2 


C/0 


M/M+Gp 


M/M+Gp 


Cf 


Cf 


Cf 


Cf 


Cf 


Cf 


C/L 


M 


M 


CLp 


CLp 


CLp 


CLp 


CLp 


CLp 


Modes 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


Cf 


Cf 


Cf 


Cf 


Cf 


C/L 


M 


M 


M 


CLp 


CLp 


CLp 


CLp 


CLp 


Mode 4 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


Cf 


Cf 


Cf 


Cf 


C/L 


M 


M 


M 


M 


CLp 


CLp 


CLp 


CLp 


Mode 5 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


Cf 


Cf 


Cf 


C/L 


M 


M 


M 


M 


M 


CLp 


CLp 


CLp 


Mode 6 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


Cf 


Cf 


C/L 


M 


M 


M 


M 


M 


M 


CLp 


CLp 


Mode 7 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


Cf 


C/L 


M 


M 


M 


M 


M 


M 


M 


CLp 


O 
O 

U) 
CD 

8 
< 

CQ 


Modes 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


C/L 


M 


M 


M 


M 


M 


M 


M 


M 


Mode 9 


C/0 


M/M+Gp 


IpF 


IpF 


IpF 


IpF 


IpF 


IpF 


IpF 


C/L 


M 


SIpp 


SIpp 


SIpp 


SIpp 


SIpp 


SIpp 


SIpp 


Mode 10 


C/0 


M/M+Gp 


M/M+Gp 


IpF 


IpF 


IpF 


IpF 


IpF 


IpF 


C/L 


M 


M 


SIpp 


SIpp 


SIpp 


SIpp 


SIpp 


SIpp 


Mode 1 1 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


IpF 


IpF 


IpF 


IpF 


IpF 


C/L 


M 


M 


M 


SIpp 


SIpp 


SIpp 


SIpp 


SIpp 


Mode 12 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


IpF 


IpF 


IpF 


IpF 


C/L 


M 


M 


M 


M 


SIpp 


SIpp 


SIpp 


SIpp 


Models 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


IpF 


IpF 


IpF 


C/L 


M 


M 


M 


M 


M 


SIpp 


SIpp 


SIpp 


Mode 14 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


IpF 


IpF 


C/L 


M 


M 


M 


M 


M 


M 


SIpp 


SIpp 


Mode 15 


C/0 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


M/M+Gp 


IpF 


C/L 


M 


M 


M 


M 


M 


M 


M 


SIpp 


*1 = E-t 


ype mux, C 


P only: B/ 


V codes 010 or 011 











For D64/D67 long slot operation with j=640/672 the A-field header coding (BA bits) shall distinguish between the 
following modes: 

• E-type, Cp only: mode (BA bits codes "010" and "Oil"); 

• E-type, M + Gp+Cp modes 1 to 7 (BA bits codes "100" and "101"); 

• E type, M + Gp : mode 8: (BA bit code "110"); 

• E+U type, M + Gp+Ipp : modes 9 to 15: (BA bit codes "110" and "111"). 

BA bit code "111" shall only be used if regular (U-type) MAC service is Ip-error-correct. 
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A. 2.4.2. 3 Half slot (j=80) modes for 2-level modulation (remove from clause 6.2.2.3.2 
of EN 300 175-3) 

The following text of clause 6.2.2.3.2 of EN 300 175-3 [3] shall be removed: 

When in E mode, the following priority scheme shall be used to fill the Bq subfield in connection oriented services: 

1) Release: bearer release messages for this bearer may be placed in Bq. 

2) Retransmissions of Cj-. 

3) MAC layer control (excluding Null message). 

4) New Cp data. 

5) New Gp data. 

6) Null Message: U-type information should normally be sent in preference to this. 
For connectionless services, CLp data has priority over MAC control. 

A.2.4.2.4 Half slot (j=80) modes for 2-level modulation (add to clause 6.2.2.3.2 of 
EN 300 175-3) 

The following note shall be added to clause 6.2.2.3.2 of EN 300 175-3 [3]: 

NOTE: Eh-U type mode is not applicable to half slot (j=80) with 2-level modulation. 

A.2.4.3 Priority scheme in E or E-i-U mode (add to clause 6.2.2 of 
EN 300 175-3) 

A new clause with the following text shall be added to clause 6.2.2 of EN 300 175-3 [3]: 

6.2.2.4 Priority scheme in E or E-i-U mode 

For Connection Oriented services (C/O) and when E/U mux is in E or Eh-U mode, the following priority scheme shall 
be used to fill the B-subfields: 

1) Release: bearer release messages for this bearer may be transmitted and may be placed in all subfields. 

2) Bearer quality control in an asymmetric connection: in an asymmetric connection a "Bearer quality in an 
asymmetric connection" message (see clause 7.3.4.4), if used, shall be placed in the subfield Bq. 

3) Other MAC layer control (excluding Null message): this may be placed in the remaining subfields. The 
subfields are used in the following order of preference, BO, Bl, B2, B3, B4, B5, B6, B7, B8, B9. 

4) Retransmissions of C^: for retransmissions of B-fields containing Cp, the same mode shall be used (note 1). 

5) New Cp data: any remaining subfields may be used for Cp data. The subfields are used in the following order 
of preference, Bj,^, Bj,^.^, ...,Bj, Bq. However, the sequence of data through the MC SAP shall be 

Bq,Bi, ...,BN.iBN(notel). 

6) Gp data: this may be placed in any subfield that has not yet been used. The order of usage of subfields and the 
sequence of data segments through the MC SAP is not specified (note 2). 

7) Remaining Ipp packets of partially transmitted PDUs and NULL message carrying segmentation info if 
needed (notes 3, 4 and 7). 

If there is no channel with priority 1 to 7 to be transmitted in the slot, THEN, the E/U-mux shall go to U-type mux 
mode. The priorities 8 and 9 only apply if the E-mux is set because one or more channels with priority 1 to 7 are 
present. 
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8) Ipp packets carrying the first part of a PDU and NULL message carrying segmentation info if needed (notes 3, 

4, 5 and 7). 

9) Null message: this shall be used to fill any subfields still empty (note 6). 
NOTE 1: This only applies to E-type mux mode. Incompatible with channel Ipp. 

NOTE 2: In some LU services (LUlO), it is possible to avoid the use of the Gp channel by using other mechanism 
for transmitting the acknowledgement information. It is advisable to do that, when there is no other 
reason for using E-mux mode multiplexing. 

NOTE 3: A Gp of a NULL message should be always in the same slot as Ipp data. In some cases, a NULL message 
is mandatory. 

NOTE 4: This only applies to E+U-type mux mode. Incompatible with Cp channel. 

NOTE 5: ONLY if there is other reason for setting the E/U mux in E or E+U mode. Otherwise the E/U-mux should 
go to U mode. 

NOTE 6: It applies to the filling of remaining subfields. If there is no other channel for multiplexing, then the 
E/U-mux should go to U-mux mode. 

NOTE 7: Items 7 and 8 are not applicable to half slot (DOS) and 2-level modulation. 
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A.2.5 B-field identification, BA bits (modify clause 7.1 .4 of 
EN 300 175-3) 

Table 7.2 in clause 7.1.4 of EN 300 175-3 [3] shall be modified as follows: 



7.1.4 B-field identification, BA, 



bits 84 to Be 



Table 7.2: B-field ID 



84 


85 


ae 


B-field contents 











U-type, 1^, Sl^j, or Ip packet number or no valid lp_error_detect channel data 








1 


U-type, lp_error_detect or Ip packet number 1 or Sl^ or no valid 1^ channel data 





1 





E-type, all Cp or CLp, packet number 





1 





double slot required 





1 


1 


E-type, all Cp, packet number 1 










E-type, not all Cp or CLp; Cp packet number (note 5) 










half slot required 







1 


E-type, not all Cp; Cp packet number 1 (note 5) 







1 


long slot (j=640) required 




1 





E+U-type, If^, lp_error_detect OR E+U type lp_error_correct packet number OR E-type all 
MAC signalling (Notes 3, 4 and 5) 




1 





long slot (j=672) required 




1 


1 


E+U-type, lp_error_correct packet number 1 OR no B-field if 1^ or lp_error_detect (notes 3, 
4, 5 and 6) 


NOTE 1 : The 000 code may be used to indicate that the B-field does not contain valid data, only for an 
already established lp_error_detect connection. 

NOTE 2: The 001 code may be used to indicate that the B-field does not contain valid data, only for an 
already established 1^ connection. 

NOTE 3: The E+U type mux (codes 1 1 and 111) allows the transmission of MAC messages (e.g. bearer 

quality report for a duplex bearer of an asymmetric connection) and U-type data in one B-field. 
NOTE 4: The 1 1 1 is only used to indicate E-hU mux if IVIAC service is lp_error_correct. For 1^ , S!,^ and 

lp_error_detect , this code indicates no valid B-field. 
NOTE 5: All MAC control (all subfields carrying MAC signalling or Gp) can be also transmitted using codes 

100 and 101 if Cp channel is supported, and 1 1 1 if MAC service is lp_error_correct. 
NOTE 6: For lp_error_correct, no B-field may be implemented using the MAC control message "NULL" in all 

subfields. 



A.2.6 Extended fixed part capabilities (part 2) (modify 
clause 7.2.3.1 1 of EN 300 1 75-3) 

Clause 7.2.3.11 of EN 300 175-3 [3] shall be modified as follows: 

7.2.3.1 1 Extended fixed part capabilities (part 2) 

7.2.3.11.1 General, Qh = (hex) 

NOTE: Bit a23 of the extended FP capabilities message (see clause 7.2.3.5) indicates whether or not this message 
is broadcast. 



1100 


Extended physical and 

IU1AC layer capabilities 

(part 2) 


Extended higher layer 
information (part 2) 


a8 all 


a12 a23 


a24 a47 



Figure 7.15c 
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7.2.3.1 1 .2 Extended physical and MAC layer capabilities (part 2) 

If a capability is available: 

THEN bit a^ shall be set to 1; 

ELSE (capability is not available) the bit a^ shall be set to 0; 
Reserved bits shall be set to 0. 

Table 7.16b 
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Bit number 


Capability 


a-|2 


Long slot support (j = 640) 


^13 


Long slot support (j = 672) 


ai4 


E+U-type mux and channel Ipp basic procedures supported (see note 1) 


ai5 


channel Ipp advanced procedures supported (see note 1) 


ai6 


channel SIpp supported (see notes 1 and 2) 


^17 


channel Gp supported (see note 3) 


^18~^23 


Reserved for future standardization 


NOTE 1 : See clauses 5.3.1 .4 and 6.2.2.2 for description of fine Ipp channel and the E+U- 

type multiplexer. 
NOTE 2: Requires the support of the Sip channel. See clause 5.3.2.3 for description of SIpp 

channel. 
NOTE 3: This bit indicates that the FT has the ability to receive the Gp channel. 



7.2.3.11.3 



Extended higher layer capabilities (part 2) 



The coding and the meaning of these bits are defined in annex F of EN 300 175-5 [5]. The bits for which the coding is 
not defined shall be set to 0. 

A.2.7 Messages in the B-field 

A.2.7.1 Messages in tine B-field, Overview (modify clause 7.3.1 of 
EN 300 175-3) 

Clause 7.3.1 of EN 300 175-3 [3] shall be modified as follows: 

7.3 Messages in the B-field 

7.3.1 Overview 

Messages may be carried in the B-field only when operating in the E-type or E-nU-type multiplex (see clause 6.2.2.2). 
Each B-field message occupies one subfield, and different subfields will usually carry a different message. The possible 
arrangements of B-field messages are defined by the E/U-MUX algorithm defined in clause 6.2.2.3 and 6.2.2.4. 

All B-field messages have a fixed length of 64 bits. 

MAC B-field messages are used to: 

1) set-up, maintain and release bearers and connections; 

2) provide extra flow, error and quality control in symmetric connections; 

3) carry Gp channel data; 

4) transport extended system information and TARI information; 
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5) exchange information about Ipp channel segmentation in E+U type mux; and 

6) fill the B-field if there are insufficient MAC, Cp, Gp, or Ipp segments to fill the whole of the B-field. 

A Mgj^ message is a B-field MAC layer control message sent in the Bn subfield. Mg^^ messages are sent in 80 bit 
packets using the E mapping described in clause 6.2.2.2. This allows Mgj^ messages to be compatible across all types of 
packets. Within the 80 bits, the format is as given in figure 7.1. 



d(64 + n X 80) 








d(143 + nx80) 


MBn 
header 


MorGp 


16 bit 
CRC 


bPo bng 


bn4 




bngs 


bng4 briyg 



Figure 7.1 : B-field messages 

"n" denotes the number of the subfield in the B-field. For the D08 field, n = 0, while for the D32 field n={0,l,2,3}. The 
CRC calculation is described in clause 6.2.5.2. 

The Mgjj header defines whether the message contains M or Gp channel data and whether another Mg^j message follows 
in the next Bn subfield. In a full-slot transmission, up to 4 messages can be sent in the B-field. 

Table 7.1 



MBn header 


Message type 


bng bng 




X 











reserved 


X 








1 


advanced connection control 


X 





1 





Null or Ipp segmentation information 


X 





1 


1 


quality control 


X 


1 








extended system information 


X 


1 





1 


Gp channel data packet 


X 


1 


1 





reserved 


X 


1 


1 


1 


escape 



The meaning of the MSB bit of the MBn header (bng) is the following: 

For half slot 2-level modulation: 

X = 1: the bit shall be set to "1" in all cases. 

For all other slot types and modulation levels: 

• For Eh-U type mux (B-field identification, BA=110orBA=lll, see 7. 1.4): 

X = 1: subfield B(n + 1) exists and contains a Mgj^ or Gp message, or subfield B(n) is the 
last subfield in this slot; 

X = 0: subfields B(n + 1) and all following in this slot contain Ipp (or SIpp) segments. 

• For E-type mux (B-field identification, BA=100 or BA=101, see 7.1.4): 

X = 1: subfield B(n + 1) exists and contains a Mgj^ or Gp message, or subfield B(n) is the 
last subfield in this slot; 

X = 0: subfields B(n + 1) and all following in this slot contain Cp or CLp segments. 
NOTE: There are no MBn headers in E-type-all-Cp mux mode (BA=010 or BA=01 1). 
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A.2.7.2 Null or Ipp segmentation info (modify clause 7.3.3 of EN 300 1 75-3) 

Title and content of clause 7.3.3 of EN 300 175-3 [3] shall be modified as follows: 



7.3.3 



Null or Ipp segmentation info 



This message has two meanings depending on the NCF codes: 

• Filling Bn subfields when there is no I data or Cp data or Gp data or other Mg^^ messages to send (NULL). 

• To transport segmentation info of the Ipp data channel (Ipp segmentation info). 





NCF 


extended NCF 


Spare or segmentation info 


X 


1 











brig 


bng 




bn4 briy 


bng bn^5 


bn^e bngg 



Figure 7.76 



Table 7.50 



NCF 


Meaning 














no Op or CLp data in the B-field 













one B-subfield contains Cp or CLp data 













two B-subfields contain Cp or CLp data 












three B-subfields contain Cp or CLp data 





1 








four B-subfields contain Cp or CLp data 





1 







five B-subfields contain Cp or CLp data 





1 







six B-subfields contain Cp or CLp data 





1 






seven B-subfields contain Cp or CLp data 













eight B-subfields contain Cp or CLp data 












nine B-subfields contain Cp or CLp data 












This is an E+U slot, and the U part contains the first part of a DLC PDU (see note 4) 











This is an E+U slot, and the U part contains the first part of a DLC PDU, and the rest 
of the PDU is empty (filling with padding bits, see notes 1 , 2 and 4) 




1 








This is an E+U slot, any other case, (see notes 3 and 4) 




1 







} 


to 


} reserved 




1 


1 





1 




1 


1 


1 


the multiplex for 4-level, 8-level, 16-level and 64-level is indicated in bits bng to bn^g 


NOTE 1 : If the transmitter uses this code, it should not transmit more segments of the PDU. 

NOTE 2: Padding bits are defined by the DLC layer (see EN 300 175-4 [4]). 

NOTE 3: The bits bn-| g to bng3 contain additional information for the segmentation control. 

NOTE 4: This message, when NCF codes are "101 0", "1011 " or "1 1 00" is considered segmentation info for E/U- 
MUX priority scheme (clause 6.2.2.4). 
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7.3.3.1 Spare or Ipp segmentation info 

For NCF = " 1 100" this field carries the following information: 

Table 7.50a 
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Octet 


bits 


meaning 


1 


bn16-bn23 


Send sequence number of the first PDU transported in this slot (note 1) 


2 


bn24 


9'" bit of the send sequence number (note 2) 


2 


bn25 


=1 Indicates this is the last segment of the PDU 


2 


bn26 


=1 Indicates that the rest of the PDU shall be filling with padding (note 3) 


2 


bn27 


=1 Indicates that there is a second PDU segment in this slot 


2 


bn28-bn31 


Sequence number of the PDU segment (note 4) 


3 


bn32-bn39 


Size (in blocks of 64 bits) of the PDU segment (note 5) 


4 


bn40-bn47 


only used if bn27=1 . Same meaning as octet 1 , but for the second PDU 
(notes 6, 7). 


5 


bn48-bn55 


only used if bn27=1 . Same meaning as octet 2, but for the second PDU 
(notes 6, 7). 


6 


bn56-bn63 


only used if bn27=1 . Same meaning as octet 3, but for the second PDU 
(notes 6, 7). 


NOTE 1 
NOTE 2 
NOTE 3 
NOTE 4 
NOTES 

NOTE 6 
NOTE? 


Copy of the first octet of the PDU. 

Applicable only to some LU frames (LU10). If not used, it shall be set to "0". 
In this case, the rest of the PDU shall not be transmitted. 
Sequence number of the segment (1 ,2,3,4 .etc.). 

For first PDU segment, the size is the number of 64 bit blocks from the beginning of the U-plane 
section to the end of the PDU segment. It shall be < number of subfields available. 
If used, the second PDU starts immediately after the first one (position indicated by octet 3). 
: If octets 4-6 are not used, they shall be filled with "0000 1111". 



For any other value of NCF, this field shall be padded with the pattern "0000 1111 0000 1111 0000 1111". 

A.2.7.3 Bearer quality in an asymmetric connection (add to clause 7.3.4.4 of 
EN 300 175-3) 

The following note shall be added to clause ?.3.4.4 of EN 300 l?5-3 [3]: 

7.3.4.4 Bearer quality in an asymmetric connection 

NOTE: This message was formerly called "MAC-mod2-ACK". 

A.2.7.4 Gp channel data packet (modify clause 7.3.6 of EN 300 1 75-3) 

Table ?.55 in clause ?.3.6 of EN 300 l?5-3 [3] shall be modified as follows: 

7.3.6 Gp channel data packet 



X 


1 1 


NCF 


56 bit Gp channel SDU 


bno 


bng 


bn4 bny 


bng 




bngs 



Figure 7.85 
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Table 7.55 



NCF 


Meaning 














no Cp data in the B-field 













one B-subfield contains Cp data 













two B-subfields contain Cp data 












three B-subfields contain Cp data 





1 








four B-subfields contain Cp data 





1 







five B-subfields contain Cp data 





1 







six B-subfields contain Cp data 





1 






seven B-subfields contain Cp data 


1 











eight B-subfields contain Cp data 


1 










nine B-subfields contain Cp data 


1 










This is an E-i-U slot, and the U part contains the first part 
of a DLC PDU 


1 









This is an E-i-U slot, and the U part contains the first part 
of a DLC PDU, and the rest of the PDU is empty (filled 
with padding bits, see notes 2 and 3) 


1 


1 








outstanding subfields, see note 


1 


1 







1 outstanding subfield, see note 


1 


1 







2 outstanding subfields, see note 


1 


1 






> 2 outstanding subfields, see note 


NOTE 1 : If there are more than 9 subfields in total, then the outstanding subfields are 

indicated. 
NOTE 2: If the transmitter uses this code, it shall not transmit more segments of the PDU 
NOTE 3: Padding bits are defined by the DLC layer (see EN 300 1 75-4 [4]). 
NOTE 4: NCF codes "1 01 0" and "1011" and "1 1 00" are considered segmentation info for 

E/U-MUX priority scheme (see clause 6.2.2.4). 



A.2.8 Q2 and BCK bit setting for lp_error_correction services 
(modify clause 10.8.2.4.1 of EN 300 175-3) 

Title of clause 10.8.2.4.1 of EN 300 175-3 [3] shall be modified as follows: 

1 0.8.2.4.1 Q2 and BCK bit setting for lp_error_correction services 

A.2.9 IpF Procedure description (add to clause 10.8 of 
EN 300 175-3) 

A new clause with the following text shall be added to clause 10.8 of EN 300 175-3 [3]: 

1 0.8.4 Higher layer U-plane channel (Ipp) in E+U type mux 
1 0.8.4.1 Purpose of the Ipp channel 

The Ipp channel is used to transport U-plane data over slots with B-field multiplexer type Eh-U (see clause 6.2.2) and 
not all subfields used by signalling channels. Ipp allows to use the remaining subfields of the slot for transporting user 
data. 

The Ipp channel transports data packets of the standard size (PDU) defined by the MAC plane service in use (Ip or Ipg) 
and slot type. In order to insert these packets over the reduced capacity Eh-U slot, the Ipp channel uses an adaptation 
procedure that transport information on the PDU boundaries by means of MAC layer messages. 
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Ipp channel could be used either if the regular I service is I^ Ip or IpQ, and either if the service is provided with error 
correction (Ip_error_correct) or error detection only (Ip_error_detect). 

NOTE: The primary utility of the Ipp channel is the transmission of limited amount of U-plane data (i.e. 
acknowledgement messages) over the reverse bearer of asymmetric data connections. 

1 0.8.4.2 Activation of the E+U type mux mode 

The B-field multiplexer enters in E+U mode due to the existence of signalling data (channels Gp and M) to be 
transmitted according to the priority rules defined in clause 6.2.2.4. The activation of the E+U mode has the 
consequence of closing the Ip or Ipg channel over the bearer, and simultaneously opening a reduced rate Ipp channel 
using the spare capacity of the bearer. 

The number of subfields used for U-plane data and C-plane signalling varies depending on modulation, slot type, and 
amount of signalling to be transported. The possible combinations are defined in clause 6.2.2.3.1. 

At least one subfield with signalling should exist. Subfields transporting signalling shall precede subfields carrying Ipp 
channel data. 

If there are not enough signalling messages plus Ipp channel segments to fill the slot, the slot shall be filled with the 

MAC message "NULL" (clause 7.3.3) repeated as many times as needed and placed at the end of the signalling 
subfields and before the Ipp channel segments. 

Once the B-field mux enters in E+U mode, this mode is kept until the end of C-plane transmission, and until the total 
transmission of a complete MAC U-plane packet (equivalent to a DLC PDU). When there is no reason to keep the E+U 
type mode, the slot passes to U-mode with the MAC service in use. 

The E+U type mux mode is indicated by the code "110" in the B-field identification bits (BA header) in A-field. The 
code "111" is also used if MAC service is Ip_error_correct. 

NOTE: It not possible to use E+U mux type for transmission of Cp higher layer signalling channel. 

10.8.4.3 IpF procedures 

Ipp channel uses specific procedures in order to adapt the size of the standard MAC packet (equivalent to the DLC 
PDU) to the reduced and variable size of the E+U slot U plane subfields. There are two sets of procedures: 

• Basic procedures. 

• Advanced procedures. 

Basic procedures guarantees Ipp channel operation. Advanced procedures increases efficiency in usage of all available 
subfields in the slot. 

In addition to them, there are specific procedures for Mod-2 protected operation. 

1 0.8.4.3.1 Ipp basic procedures 

Basic procedures allow the transportation of a single segment of MAC packet (DLC PDU) in each E+U type slot. The 
transmitter side segments the packet according to the available U-plane subfields. However, if the PDU contains filling 
area (the SDU ends before the end of the PDU), the transmitter side may remove the padding bits, by placing a special 
code in the signalling control message described later in this clause. 

The following cases could happen: 

• Case 1 : The slot carries the first part of a MAC packet (DLC PDU). 

• Case 2: The slot carries the first and only part of a MAC packet (DLC PDU). 
NOTE 1 : Case 2 can only happen due to the padding removal option described above. 
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• Case 3: The slot carries the n* part, but not the last, of a MAC packet (DLC PDU). 

• Case 4: The slot carries the n* and last part of a MAC packet (DLC PDU). 

NOTE 2: In 2-level modulation, double or long slots, with the expected signalling needs, cases 1, 2 and 4 will 
happen with relative probability, while case 3 will be rare. 

NOTE 3: In the reverse channel of asymmetric connections carrying Internet Protocol (IP), case 2 will happen with 
high probability due to the relatively short TCP acknowledgement packets. 

In cases 1 and 2, the slot shall carry at least one Gp channel packet or "NULL and Ipp segmentation info" message. If no 
Gp channel packet is to be transmitted, then the message "NULL or Ipp segmentation info" shall be inserted in one of 
the signalling subfields of the slot. 

In cases 3 and 4, a message "NULL or Ipp segmentation info" shall be, in any case, inserted in one of the signalling 
subfields (see clause 7.3.3). 

The NCF field of the Gp or "NULL or Ipp segmentation info" shall carry the following codes: 

Case 1: "1010". 

Case 2: "1011". 

Cases 3 or 4: "1100" only in a "NULL or Ipp segmentation info" message. 

In cases 1 or 2, if the NCF header is in a "NULL or Ipp segmentation info" message, the content of the "segmentation 
info" field in the message is irrelevant. 

In cases 3 and 4, only, the octets 1, 2 and 3 of the "segmentation info" field in the "NULL or Ipp segmentation info" 
shall be written by the transmitter and shall be analyzed by the receiver. The meaning of such octets is defined in 
clause 7.3.3.1. By analysing this information, the receiver side could reconstruct the original MAC packet (DLC PDU). 

In all cases, the PDU segment shall start in the first U-mode subfield in the slot. Note that there could be unused space 
at the end of the U-type area. 

1 0.8.4.3.2 Ipp advanced procedures 

Advanced procedures add the possibility to have two PDU segments (two segments belonging to two consecutive DLC 
PDUs) in the same E+U mux slot. The number of possible cases is increased. In turn of that, the E+U slots can be filled 
more efficiently. 

NOTE 1: In previous paragraph the word "consecutive" refers to the sequence of PDUs as received from the DLC 
by the MAC layer. The DLC sequence numbers may not necessarily be consecutive due to DLC 
retransmissions. 

In order to implement advanced procedures, the bit bn27 in octet 2 and the octets 4, 5 and 6 in the "NULL or Ipp 
segmentation info" message shall be filled by the transmitter and analyzed by the receiver. The two segments of PDUs 
shall be packed one after the other, starting in the first U-mode subfield in the slot. There could be unused space at the 
end of the U-type area. 

NOTE 2: The maximum number of PDU segments in the same slot is limited to two. 

1 0.8.4.3.3 Special case: slots not multiple of 64 bits 

In some rare cases, the MAC packet size (DLC PDU size) of the Ip or Ipg slot is not a multiple of 64 bits. This happens, 
for instance, with long slot 640 and MAC IpQ mode. 

If the MAC packet size is not a multiple of 64 bits, it shall first be filled to the next 64 bits multiple, and then the normal 
Ipp procedures shall be used. The receiver side shall remove the padding bits before delivering the packet to higher 
layers. 

NOTE: Note that in this case, the number of padding bits is a constant well known to both peers. 
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10.8.4.4 IpF Mod-2 protected operation 



The Ipp channel inherits the behaviour of the regular Ip or IpQ U-plane MAC service. If the MAC service is 
"error_correct" then the Ipp channel shall operate also in "error correction mode". 

The Ipp channel also inherits the value of the "MAC lifetime" parameter used in the regular U-plane service. 

The operation of the Ipp channel in error correct mode shall use the same procedure as the Ip or IpQ channel 
(clause 10.8.2), with the following specific previsions: 

4) The series of E+U type slots shall be an independent MOD-2 sequence, different of the sequence of 
Ip_error_correct slots transmitted before or after the Eh-U mode. 

5) From the point of view of the main Ip_error correct sequence, the insertion of Eh-U slots produces an Ip bearer 
reset (see clause 10.8.2.5.3). 

6) If there were Ip packets pending for retransmission when the slot changes to Eh-U type mode, the transmitter 
side could, at its choice, reschedule the packet in the Ip channel of other bearer (if available), or pass the packet 
to the new Ipp channel. However, the "MAC lifetime" counter should be passed with the proper value. 

7) The E+U slots shall be MOD-2 numbered by using, alternatively, the BA codes "110" and "111" (see table 7.2 
in clause 7.1.4). 

8) The MOD-2 receiver may use selective reception for building all subfields in the E+U slot. 

9) The Gp channel and the "NULL or Ipp segmentation control" message, when NCF indicates any type of 
segmentation control, shall be always retransmitted together with U plane subfields. 

10) The bearer quality message "MAC-MOD-2-ACK" shall never be retransmitted. Instead of them, a "fresh" 
message shall always be placed in the same subfield. 

11) The retransmission or not of other MAC messages is free to the implementer. It is allowed to insert new MAC 
messages (or NULL) in these subfields when slot is retransmitted. 

12) The insertion of an "all MAC control" (E-type, codes 1 10 or 1 1 1) field does not break the MOD-2 sequence. In 
this case the BA code 1 10 or 111 shall be used according to the sequence and the retransmission behaviour 
shall be as described in this clause. 

NOTE: This is the only case when the BA code 111 could be used for an E-type "all MAC control or Gp" slot. 

13) However, if the E/U mux has to switch to "E-type mux, Cp only" or "E-type mux with Cp" (BA codes 010, 
Oil, 100 or 101), this breaks the sequence, and the numbering and retransmission of the slot shall be ruled by 
the Cp channel rules (clause 10.8.1.2). 

14) In case of multibearer, it is allowed to retransmit a badly received bearer over another E+U type bearer. 
However, the packet lifetime counter shall be passed to new bearer with the proper value. This operation 
causes a "jump" (see 10.8.2) for the first bearer. 

10.8.4.5 lpF_error_detect operation 

When the regular MAC service is Ip (or Ipg) error detect, the Ipp channel shall operate without retransmission, however 
with CRC error detection capability. In such cases, only the B-field (BA) code "110" shall be used. There shall not be 
MAC retransmission of any channel in E+U type slots. 

10.8.4.6 lpF_operation with 1^ service 

When the regular MAC service is If^, the Ipp channel shall operate without retransmission, with the same format and 
procedures as for Ip_error_detect. However, packets shall be assembled at the receiver side, even in the case of CRC 
error of individual Ipp subfields. The CRC of A-field should be, however, correct to accept a packet. Subfields carrying 
segmentation info should be also received with correct B-field CRC. 
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10.8.4.7 Backcompatibility rule 



The support of Ipp channel and E+U-type mux by PT or FT shall be indicated by a flag in the <Terminal capability> 
Information Element (see EN 300 175-5 [4] clause 7.7.41) and in "Extended higher layer capabilities (part 2)" broadcast 
(see EN 300 175-5 [4] annex F.3). This flag indicates the support of both, channel Ipp and E-nU-type mux mode. 

The transmitter side shall not set E-nU-type mux mode if the receiver side does not support Ipp channel. 

NOTE: However, the transmitter side may use the BA code " 1 10" for transmission of E-type, all MAC control, 
mux mode. 



A.3 Amendments to EN 300 1 75-5 (DECT CI; NWK 



layer) 



The following amendments to EN 300 175-5 [5] shall apply for the purpose of the present document. 

A.3.1 References (add to clause 2 of EN 300 175-5) 

The following entries shall be added to clause 2 "References" of EN 300 175-5 [5]: 

[76] ETSI TS 102 527-1: "Digital Enhanced Cordless Telecommunications (DECT); New Generation 

DECT; Part 1: Wideband speech". 

A.3.2 Terminal capability (add to clause 7.7.41 of EN 300 175-5) 

The following codings of Profile/ Application Indicator 6 and 7 (Octets 4e and 4f) and notes shall be added to 
clause 7.7.41 of EN 300 175-5 [5]: 

7.7.41 Terminal capability 

Profile/Application Indicator_6 Coding (Octet 4e): 

Bits 7 6 5 4 3 2 1 Meaning 

X X X X X X 1 DECT/UMTS interworking profile supported (TS 101 863 [64]) 

X X X X X 1 X DECT/UMTS interworking - GPRS services supported (TS 101 863 [64]) 

X X X X 1 X X Basic ODAP supported (TS 102 342 [73]) 

X X X 1 X X X F-MMS Interworking profile supported (TS 102 379 [74]) 

X X 1 X X X X E-nU-type mux and channel Ipp basic procedures supported (see note 15) 

X 1 X X X X X Channel Ipp advanced procedures supported (see note 15) 

1 X X X X X X Channel SIpp supported (see notes 15 and 16) 

Profile/Application Indicator_7 Coding (Octet 4f): 

Bits 7 6 5 4 3 21 Meaning 

X X X X X X 1 64-level modulation scheme supported (Bh-Z field) 

X X X X X 1 X NG-DECT Part 1 : Wide band voice supported (TS 102 527-1 [76]) 

X X X NG-DECT Packet Data: No packet data supported or non categorized system (see note 17) 

X 1 X X NG-DECT Packet Data Category: Cat 1 (low-end data devices, see note 17) 

X 1 X X NG-DECT Packet Data Category: Cat 2 (mid-end data devices, see note 17) 

X 1 1 X X NG-DECT Packet Data Category: Cat 3 (high-end data devices, see note 17) 

X 1 X X X X Reserved for future Data Categories 

X 1 X X X X Reserved for future Data Categories 

X 1 1 X X X X Reserved for future Data Categories 

1 X X X X X X Channel Gp supported (see note 18) 

NOTE 15: See EN 300 175-3 [3] for description of the Ipp channel and the E-nU-type mux. 
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NOTE 16:Requires the support of the Sip channel. See EN 300 175-3 [3] for description of SIpp channel. 

NOTE 17: See the data profile specification for exact definition of Packet data Categories (bits 3 to 6 of Octet 4f). 
Packet data Categories are incremental: Cat 3 systems also support Cat 1 and Cat 2; Cat 2 systems also 
support Cat 1 . 

NOTE 18: This bit indicates that the PT has the ability to receive the Gp channel. 

A.3.3 Extended higher layer capabilities (part 2) (modify 
clause F.3 of EN 300 175-5) 

Clause F.3 of EN 300 175-5 [5] shall be modified as follows: 

F.3 Extended higher layer capabilities (part 2) 

If a profile is supported or a capability provided, then the bit corresponding to that profile is set to 1 ; otherwise (if 
profile/capability is not supported) the bit is set to 0. 

For NG-DECT systems supporting packet data, the system category is indicated by bits a25 - a28. 

Table F.3: Extended higher layer capabilities 



Bit number 


Profile supported 


a24 


NG-DECT Wideband voice (see TS 102 527-1 [76]) 


a25 - a28 


NG-DECT Pacl<et Data Category (see table F.3a) 


a29 - a47 


Reserved for future standardization 



Table F.3a: NG-DECT DPRS Packet data Category (Cat) 



Bits 
a25 - a 28 


NG-DECT Packet Data Category supported 


0000 


No Packet data supported or non categorized system 


0001 


Cat 1 : data Category 1 (see note 3) 


0010 


Cat 2: data Category 2 (see note 3) 


0011 


Cat 3: data Category 3 (see note 3) 


All other values 


Reserved for future standardization 



NOTE 1: The bit numbers refer to the bit positions in the MAC message. Refer to EN 300 175-3 [3], 
clause 7.2.3.11. 

NOTE 2: The default setting for all bits is "0"; meaning "not available". 

NOTE 3: See the data profile specification for exact definition of Packet data Categories. Packet data Categories 
are incremental: Cat 3 systems also support Cat 1 and Cat 2; Cat 2 systems also support Cat 1 . 
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